[Cuis] CSV Parser in Cuis available // issue about parsing hexadecimal number with lower case letters

[H. Hirzel]

Hello Sven

Yes, that would make it work. But do we want that? A test suite that
senses the environment where it is run in and lowers the barriers
accordingly?

Then I rather prefer a failing test and I change the test on the Cuis
side and document that in the porting log.

Make it explicit that people see what was changed.

In this case the impact is minimal, I think. People for whom the lower
case hexadecimal numbers are an issue can do the fix themselves.

Or we change the number parser in NeoCSV to do an #asUpperCase before
asking for the digitValue?

The goal is that repeated porting exercises are smooth. Ideally only
minimal changes or none at all.

Hannes


BTW later on I'd like to do as well a port to Amber.


On 5/13/15, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> Hi Hannes,
>
> It seems indeed that Cuis consistently only handles uppercase hex, not just
> in Character, but also in ByteArray>>#readHexFrom: and #hex, while Pharo
> allows both.
>
> Maybe we could relax the test by skipping the lowercase version when $a
> digitValue ~= 10 ?
>
> Sven
>
>> On 13 May 2015, at 21:52, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>>
>> Hello Juan and Sven
>>
>> About the Cuis port of NeoCSV.
>>
>> I think for this failing test
>>
>> (1 out of 50 here
>> https://github.com/hhzl/Cuis-NeoCSV/blob/master/Neo-CSV-Tests.pck.st#L635
>> )
>>
>> we have to involve Sven van Caekenberghe, the author of the package in
>> the discussion.
>>
>> The NeoCSV package has its own number parser called  NeoNumberParser
>> to make it independent. And as you write that parser relies on $b
>> digitValue = 11 by the underlying Smalltalk core.
>>
>> So the answer is yes, if Cuis has $b digitValue = 11, the tests Sven
>> requires will work unchanged.
>>
>> However maybe he is willing not to require that parsing lower case
>> letters a..f in hexadecimal is required, as you, Juan, write that this
>> leads to ambiguity.
>>
>> So we have three options
>>
>> 1) Sven removes
>>
>> self
>> assert:
>> (NeoNumberParser
>> parse: '7b'
>> base: 16)
>> equals: 123.
>>
>> from the test to facilitate future ports (there will be soon another
>> one as he has updated the package last week end.
>>
>>
>> 2) Cuis adopts
>>        $b digitValue = 11
>>
>>
>> 3) When porting I remove the requirement self
>> assert:
>> (NeoNumberParser
>> parse: '7b'
>> base: 16)
>> equals: 123.
>>
>> from the test.
>>
>>
>> I tend to prefer option 1 or 2.
>>
>> What do you think?
>>
>> Kind regards
>>
>> Hannes
>>
>>
>> cc: to Sven
>>
>> On 5/13/15, Juan Vuletich <juan at jvuletich.org> wrote:
>>> Cool Hannes!
>>>
>>> I see that #testHexadecimalIntegers is failing. Does changing
>>> #digitValue so that $b digitValue = 11 fix this? If so, do you think
>>> that changing this behavior is risky for the regular Cuis parser? Or
>>> maybe an alternative is to change senders, and add a new method
>>> #caseInsensitiveDigitValue or similar?
>>>
>>> Thanks,
>>> Juan Vuletich
>>>
>>> On 5/9/2015 5:26 PM, H. Hirzel wrote:
>>>> Hello
>>>>
>>>> I have ported the NeoCSV package from Pharo 4.0
>>>>
>>>> Neo-CSV-Core (SvenVanCaekenberghe.21)
>>>>
>>>> Neo-CSV-Tests (SvenVanCaekenberghe.18)
>>>>
>>>>
>>>> It is available here
>>>>
>>>>     https://github.com/hhzl/Cuis-NeoCSV
>>>>
>>>> For it to work it needs the attached changeset for Cuis core.
>>>> Discussion of the addition in another thread.
>>>>
>>>>
>>>> Regards
>>>>
>>>> Hannes Hirzel
>>>
>>>
>
>