[Cuis-dev] fileout. proposed 2 new methods for strict file chunks reading

Wed Oct 20 09:16:45 PDT 2021

No worries Dave !

bye
Nicola

On 10/20/21 17:34, David T. Lewis via Cuis-dev wrote:
> Hi Nicola,
>
> I want to apologize because I think that the tone of my message was
> bad. I meant to be humorous in referring to programmers' opinions,
> but instead I think that my message sounded negative and critical.
> I'm sorry for that.
>
> I do see your point here, and thank you for taking the time to explain it.
>
> Dave
>
>
> On Wed, Oct 20, 2021 at 10:01:55AM +0200, Nicola Mingotti via Cuis-dev wrote:
>> Hi Dave,
>>
>> for me it is not a religious matter. You guys can decide whatever you wish
>> and we'll still be friends;)
>>
>> I came from an academic background so I believe I should try
>> to convince my colleagues what I say has validity, opinions are not all
>> the same,
>> permit me to insist a bit. There will not be a follow up to this,
>> insistence ends here.
>>
>> Monday i wanted to read some stupid lines from a log files
>> and I COULD NOT do it easily and CORRECTLY because the function 'upTo'
>> has logical
>> issues related to undecidability of its output.
>>
>> So, i had to:
>> 1) detect the problem
>> 2) rewrite the correct 'upTo' my self
>> => A novice programmer can't do that, he take the sort path and stick
>> with the bugous implementation.
>> => sooner or later the program will brake
>>
>> I tried to understand where this stuff come from, and i see it comes
>> from far away. See "Draft Smalltalk Ansi Smalltalk Standard pg. 280"
>> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiZsPmMutjzAhUKgP0HHdsOAyAQFnoECCQQAQ&url=https%3A%2F%2Fwiki.squeak.org%2Fsqueak%2Fuploads%2F172%2Fstandard_v1_9-indexed.pdf&usg=AOvVaw3BMiGjnp2vgwHcPe3e2_Ue
>>
>> This is a problem. On the other side, it can be written on the Bible
>> itself, but this function has
>> logical issues and this is undeniable. Now that I see it is also in the
>> Standard it is not wise
>> to change the function 'upTo' but it is definitely worth to give programmers
>> the opportunity not to make things wrong providing a method they can
>> trust: 'strictUpTo'.
>>
>>
>> bye
>> Nicola
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 10/20/21 03:10, David T. Lewis via Cuis-dev wrote:
>>> Hi Nicola,
>>>
>>> On Tue, Oct 19, 2021 at 03:32:08PM +0200, Nicola Mingotti via Cuis-dev
>>> wrote:
>>>> Hi Hernan,
>>>>
>>>> In all frankness, in I would wipe out the old 'upTo' because its
>>>> behavior is a bit "wild".
>>>>
>>> If you put a hundred programmers in a room, you will get a thousand
>>> opinions about things that are needed for programmers.
>>>
>>> The semantics of PositionableStream>>upTo: are clearly defined in the
>>> method comment. Implementing #strictUpTo: is a reasonable thing to do,
>>> but as Hernan has suggested it does not need to be in the base image.
>>>
>>> Dave
>>>
>>>
>>>> On the other side, I understand it may create problems in
>>>> retro-compatibility, that is why for
>>>> the moment i propose to add a new method which behaves a bit better.
>>>>
>>>> I hope this example explains the problem:
>>>> -------------------------------------------------------
>>>> s _ 'hello-1Ahello-2Ahel'.
>>>> '/tmp/test.txt' asFileEntry fileContents: s.
>>>>
>>>> st1 _ '/tmp/test.txt' asFileEntry readStream .
>>>>
>>>> st1 upTo: $A. " 'hello-1' "
>>>> st1 upTo: $A. " 'hello-2' "
>>>> st1 upTo: $A. " 'hel' "???????????????? "(*)"
>>>> ------------------------------------------------------
>>>> (*) You can't establish in any way if you actually found an "A"
>>>> terminated block or just hit the end of file
>>>> (*) If you hit the end of file you eat an incomplete record, this is
>>>> another problem, maybe another process
>>>> was going to end writing that record but you will never know.
>>>>
>>>> Maybe there is another method around that performs similarly to
>>>> 'strictUpTp', if there is I did not find it, sorry.
>>>>
>>>> IMHO, In a scale of importance from 0 to 10, this method, for a
>>>> programmer, >= 8.
>>>> I would definitely not put it into an external package, too much
>>>> fundamental.
>>>>
>>>> bye
>>>> Nicola
>>>>
>>>>
>>>> On 10/19/21 14:44, Hernan Wilkinson wrote:
>>>>> Hi Nicola!
>>>>> ??I was wondering, why are you suggesting adding them to the base? Is
>>>>> it not enough??to implement them as an extension in your package?
>>>>> ??Also, I think that any new functionality??should come with its
>>>>> corresponding tests to help the maintenance and understanding of the
>>>>> functionality.
>>>>>
>>>>> Cheers!
>>>>> Hernan.
>>>>>
>>>>>
>>>>> On Tue, Oct 19, 2021 at 7:04 AM Nicola Mingotti via Cuis-dev
>>>>> <cuis-dev at lists.cuis.st> wrote:
>>>>>
>>>>>     Hi Juan, guys,
>>>>>
>>>>>     I would like to add to Cuis the 2 methods i attach here. One is a
>>>>>     helper method.
>>>>>
>>>>>     -----------
>>>>>     StandardFileStream strictUpTo: delim.
>>>>>     -----------
>>>>>
>>>>>     Differently from 'upTo: delim' this method:
>>>>>     1. Does not return stuff if it does not find 'delim'.
>>>>>     2. Does not upgrade the position on the stream if does not find
>>>>>     'delim'.
>>>>>     3. If it finds 'delim' returns a chunk that includes it.
>>>>>
>>>>>     I am parsing log files at the moment, this is very much useful.
>>>>>
>>>>>     NOTE. Up to now I tested only on small files.
>>>>>
>>>>>     bye
>>>>>     Nicola
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     --
>>>>>     Cuis-dev mailing list
>>>>>     Cuis-dev at lists.cuis.st
>>>>>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> <https://10pines.com/>
>>>>>
>>>>>
>>>>>   Hern??n Wilkinson
>>>>>
>>>>>
>>>>>     Software Developer & Coach
>>>>>
>>>>> Alem 896, Floor 6, Buenos Aires, Argentina
>>>>>
>>>>> +54 11 6091 3125
>>>>>
>>>>> @HernanWilkinson
>>>>>
>>>> -- 
>>>> Cuis-dev mailing list
>>>> Cuis-dev at lists.cuis.st
>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>> -- 
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev