Ah, the heck with it. Here's an experiment I did just now. Prompt: Write a method in Pharo Smalltalk to determine the line termination convention of a text file, given the name of the file. Response: detectLineEndingInFileNamed: filename |file contents crlfCount crCount lfCount| file := FileStream readOnlyFileNamed: fileName. contents := file next: 10000. file close. crlfCount := 0. crCount := 0. lfCount := 0. 1 to: contents size - 1 do: [:index | |current next| current := contents at: index. current := contents at: index + 1. (current = 13 and: [next = 10]) ifTrue: [crlfCount := crlfCount + 1]]. 1 to: contents size do: [:index | |current| current := contents at: index. current = 10 ifTrue: [lfCount := ifCount + 1]. current = 13 ifTrue: [crCount := crCount + 1]]. ^Dictionare new at: #crlf put: crlfCount; at: #cr put: crCount; at: #lf put: lfCount; yourself. The first thing that hit me was that this was better than I expected. The second thing I noticed was that it doesn't actually solve the problem. It reports some counts, but it makes no determination. It should be something like (lfCount >= crCount and: [lfCount >= crlfCount]) ifTrue: [^#lf]. (crCount >= lfCount and: [crCount >= crlfCount]) ifTrue: [^#cr]. ^#crlf The next thing to catch my eye was the use of two loops, when one would do, and pondering that showed me that THE LF COUNT IS INCORRECT. Each line ending with CR+LF will be counted twice, once as an instance of CR+LF and once as an instance of LF. Write the loop as prev := 32 "Character space codePoint". contents do: [:each | each = 10 ifTrue: [ prev = 13 ifTrue: [crlfCount := crlfCount + 1 ifFalse: [lfCount := lfCount + 1]] ifFalse: [ each = 13 ifTrue: [crCount := crCount + 1]]. prev := each].. crCount := crCount - crlfCount. And then it hit me. Pharo doesn't *have* a FileStream class any more. It should be something like stream := fileName asFileReference binaryReadStream. Finally, some files really do have outrageously long llines. 10000 is an arbitrary choice. The only reason it's needed is to avoid trying to load a big file into memory, but the only reason to try to load a big file into memory it to scan the contents twice, which we do not need. We couldjust read all the bytes of the file one by one. But with the arbitrary limit, there will be files where this gives misleading answers. So we have a simple prompt for a simple method with four problems: - a bug that prevents running tests at all (FileStream) - a bug that will be found immediately by testing (wrong kind of answer) - a bug that will be found by testing (CR being counted twice) - a bug that will probably not be found by testing (misleading answers for large files with mixed conventions or exceedingly long first line) This has been my experience every time I've tried to use AI to generate code. Bugs bugs bugs, to the point where it's less work to write the code myself than to debug the AI's. On Mon, 11 Aug 2025 at 10:10, Richard O'Keefe <raoknz@gmail.com> wrote:

Not long ago I tried one of the freely available AI systems that was supposed to be especially good at coding problems. I gave it five simple tasks, and it horribly flubbed every one of them. Even getting *syntactically* correct code in a less common language took a lot of prompting. A while back, someone displayed some AI-generated "Smalltalk" code in this mailing list. It didn't work.

"better Pharo support" means what, exactly? Do your requirements include generating *correct* code?

It would be valuable for someone to conduct some experiments and report them here.

On Mon, 11 Aug 2025 at 08:04, Arild Dyrseth via Pharo-users <pharo-users@lists.pharo.org> wrote:

...

Has any assessment been made as to which of the LLMs currently provide the better Pharo coding support ?

Kind regards,

Arild Dyrseth

No, that beauty was my fault. The free AI deleted the response while I was in the middle of copying it (why didn't copy+paste work? Darned if I know), so I was racing to reconstruct it from memory. By the way, it's not just me who has experiences like what I intended to report. In an R blog today I came across someone who had converted R to Python using an AI tool and the translation wasn't just wrong, it managed to crash Python. I lost the place so I can't give you the link, sorry. On Mon, 11 Aug 2025 at 14:30, Richard Sargent <rsargent@5x5.on.ca> wrote:

You didn't comment on this beauty:

current := contents at: index. current := contents at: index + 1. (current = 13 and: [next = 10])

On August 10, 2025 4:23:29 PM PDT, Richard O'Keefe via Pharo-users <pharo-users@lists.pharo.org> wrote:

...

Ah, the heck with it. Here's an experiment I did just now.

Prompt: Write a method in Pharo Smalltalk to determine the line termination convention of a text file, given the name of the file. Response: detectLineEndingInFileNamed: filename |file contents crlfCount crCount lfCount| file := FileStream readOnlyFileNamed: fileName. contents := file next: 10000. file close. crlfCount := 0. crCount := 0. lfCount := 0. 1 to: contents size - 1 do: [:index | |current next| current := contents at: index. current := contents at: index + 1. (current = 13 and: [next = 10]) ifTrue: [crlfCount := crlfCount + 1]]. 1 to: contents size do: [:index | |current| current := contents at: index. current = 10 ifTrue: [lfCount := ifCount + 1]. current = 13 ifTrue: [crCount := crCount + 1]]. ^Dictionare new at: #crlf put: crlfCount; at: #cr put: crCount; at: #lf put: lfCount; yourself.

The first thing that hit me was that this was better than I expected. The second thing I noticed was that it doesn't actually solve the problem. It reports some counts, but it makes no determination. It should be something like (lfCount >= crCount and: [lfCount >= crlfCount]) ifTrue: [^#lf]. (crCount >= lfCount and: [crCount >= crlfCount]) ifTrue: [^#cr]. ^#crlf The next thing to catch my eye was the use of two loops, when one would do, and pondering that showed me that THE LF COUNT IS INCORRECT. Each line ending with CR+LF will be counted twice, once as an instance of CR+LF and once as an instance of LF. Write the loop as prev := 32 "Character space codePoint". contents do: [:each | each = 10 ifTrue: [ prev = 13 ifTrue: [crlfCount := crlfCount + 1 ifFalse: [lfCount := lfCount + 1]] ifFalse: [ each = 13 ifTrue: [crCount := crCount + 1]]. prev := each].. crCount := crCount - crlfCount. And then it hit me. Pharo doesn't *have* a FileStream class any more. It should be something like stream := fileName asFileReference binaryReadStream.

Finally, some files really do have outrageously long llines. 10000 is an arbitrary choice. The only reason it's needed is to avoid trying to load a big file into memory, but the only reason to try to load a big file into memory it to scan the contents twice, which we do not need. We couldjust read all the bytes of the file one by one. But with the arbitrary limit, there will be files where this gives misleading answers.

So we have a simple prompt for a simple method with four problems: - a bug that prevents running tests at all (FileStream) - a bug that will be found immediately by testing (wrong kind of answer) - a bug that will be found by testing (CR being counted twice) - a bug that will probably not be found by testing (misleading answers for large files with mixed conventions or exceedingly long first line)

This has been my experience every time I've tried to use AI to generate code. Bugs bugs bugs, to the point where it's less work to write the code myself than to debug the AI's.

On Mon, 11 Aug 2025 at 10:10, Richard O'Keefe <raoknz@gmail.com> wrote:

...

Not long ago I tried one of the freely available AI systems that was supposed to be especially good at coding problems. I gave it five simple tasks, and it horribly flubbed every one of them. Even getting *syntactically* correct code in a less common language took a lot of prompting. A while back, someone displayed some AI-generated "Smalltalk" code in this mailing list. It didn't work.

"better Pharo support" means what, exactly? Do your requirements include generating *correct* code?

It would be valuable for someone to conduct some experiments and report them here.

On Mon, 11 Aug 2025 at 08:04, Arild Dyrseth via Pharo-users <pharo-users@lists.pharo.org> wrote:

...

Has any assessment been made as to which of the LLMs currently provide the better Pharo coding support ?

Kind regards,

Arild Dyrseth

There is of course a major issue and several minor issues in that code. The major issue is using #contents. That's just nuts. All we ever *need* to holdin memory is 2 bytes, not the whole possibly extremely large file. The factoring in my library goes like this: BasicInputStream>>lineTerminationConvention "where the core algorithm goes" ReadOnlyByteArray>>lineTerminationCOnvention ^self readStream bindOwn: [:stream | stream lineTerminationConvention] Filename>>lineTerminationConvention ^(FileStream read: self type: #binary) bindOwn: [:stream | stream lineTerminationConvention] and having the method on ReadOnlyByteArray made it much easier to set up test cases (which of course found a bug..) Using Characters instead of bytes in this algorithm would be strongly inadvisable. In astc, one of the core functions of an external text input stream is to take care of encoding, INCLUDING line terminator, so that Smalltalk code gets a Character cr *whatever* the current line ends with, making it quite impossible for the algorithm to work with Characters. (This is one reason why the sketch I gave above does NOT include a definition for ReadOnlyString>>lineTerminationConvention, although it easily could; the only line termination that ever has any business turning up in a string is Character cr. This was very carefully engineered and makes life SO much simpler.) Guessing the line termination convention is a matter of inspecting the EXTERNAL ENCODING of a file, just like trying to guess whether it is Latin1 or UTF8 or UTF16. Almost by definition you have to look at the bytes; that's what it MEANS to scrutinise the external representation. I notice the presence of the magic number 0.8. Why 0.8 rather than 0.83666 or 0.7502? And of course this code raises an issue which I had not thought about in my code, which is "why base the decision on the proportion of the terminators rather than their recency?" By this I mean, suppose you write a file under Windows, some sort of log perhaps, and you get 50 lines with CR+LF terminators. And then you switch to appending to it from WSL, and you append another 40 lines with LF terminators. Shouldn't that be evidence that the convention used with the file has *changed* and it's now an LF file rather than a CRLF one? Perhaps updates should be computed using exponential decay, so that instead of fooCount := fooCount + 1 we have fooCount := fooCount * decayRate + 1. barCount := barCount * decayRate. ughCount := ughCount * decayRate. It is not clear why #unknown is distinguished from #mixed. For my purposes, it was essential that a definite decision was made. For that reason, my code *actually* uses (FileStream read: self type: #binary ifAbsent: [#[] readStream]) bindOwn: [...] to open and close the file. And that raises the question, "what is to be done when the file does not exist". And in fact we need to consider four cases: file exists and is a readable file, file exists and is a readable directory, file exists but the program has no permission to read it, and file does not exist. Again, for my purposes, the right answers were - file exists and is a readable file: process it - file exists and is a readable directory: let the opening method raise a ChannelWillNotOpen exception - file exists and is not readable: let the opening method raise a ChannelWillNotOpen exception - file does not exist: pretend it's empty. Calling #error: in this code seems rather pointless. Not that it's wrong, although it *is* an arbitrary choice not to raise an exception. The point is that a decision has been made here by the AI that is not grounded on anything in the prompt, and reporting #unknown or #mixed or the magic number 0.8 appear to also be decisions that are not grounded on anything in the prompt. Certainly not on anything in my prompt. I want to emphasise that there is nothing special about "determine the line ending convention" and that my code is surely subject to criticism in its turn. And that's precisely the point. It's not just AIs that smuggle in decisions that are not grounded in the requirements and might make the code technically correct but unfit for purpose. People do it all the time. This is why code inspections are such a useful technique. There's a dance between using the requirements to debug the code and using the code to debug the requirements, where the (pragmatically)*right* thing for the AI or the human to do is to come back and ASK "What should I do with an empty file?" or "Can I assume that files will always be small compared with Smalltalk's memory?" or "Would it be OK to look at just the first line terminator?" or any other question left unanswered by the current prompt. Perhaps it is up to us as programmers-using-AIs to start not by saying "write me a method <jabberwock> to <burble>" but by saying "write me some test cases for a method <jabberwock> that <burbles>." On Mon, 11 Aug 2025 at 21:17, Cédrick Béler <cdrick65@gmail.com> wrote:

I gave a shot to Claude Opal 4.1 (did not test as on a road trip).

Two artefacts were created.

First one

detectLineTerminationConvention: aFilename “Detect the line termination convention used in a text file. Returns #cr, #lf, #crlf, or #unknown”

``` | fileReference contents crCount lfCount crlfCount index |

"Create file reference and check if file exists" fileReference := aFilename asFileReference. fileReference exists ifFalse: [ ^ self error: 'File does not exist: ', aFilename ].

"Read file contents as binary to preserve line endings" contents := fileReference binaryReadStream contents. contents isEmpty ifTrue: [ ^ #unknown ].

"Initialize counters" crCount := 0. lfCount := 0. crlfCount := 0. index := 1.

"Scan through the content looking for line terminators" [ index <= contents size ] whileTrue: [ | currentByte nextByte | currentByte := contents at: index.

"Check for CR (13) followed by LF (10)" (currentByte = 13 and: [ index < contents size ]) ifTrue: [ nextByte := contents at: index + 1. nextByte = 10 ifTrue: [ "Found CRLF" crlfCount := crlfCount + 1. index := index + 2 ] ifFalse: [ "Found standalone CR" crCount := crCount + 1. index := index + 1 ] ] ifFalse: [ "Check for standalone LF (10)" currentByte = 10 ifTrue: [ lfCount := lfCount + 1 ]. index := index + 1 ] ].

"Determine the predominant line ending convention" (crlfCount > 0 and: [ crlfCount >= crCount and: [ crlfCount >= lfCount ] ]) ifTrue: [ ^ #crlf ].

(lfCount > 0 and: [ lfCount >= crCount ]) ifTrue: [ ^ #lf ].

crCount > 0 ifTrue: [ ^ #cr ].

^ #unknown ```

Second one : “FileLineEndingDetector - A utility class for detecting and converting line endings”

Object subclass: #FileLineEndingDetector instanceVariableNames: ‘’ classVariableNames: ‘’ package: ‘FileUtilities’

“Class-side methods”

FileLineEndingDetector class >> detectLineEndingIn: aFilename “Main method to detect line ending convention in a file”

``` | fileReference contents |

fileReference := aFilename asFileReference. fileReference exists ifFalse: [ ^ self error: 'File does not exist: ', aFilename ].

contents := fileReference binaryReadStream contents. ^ self detectLineEndingInBytes: contents ```

FileLineEndingDetector class >> detectLineEndingInBytes: aByteArray “Detect line ending convention in a byte array”

``` | crCount lfCount crlfCount index result |

aByteArray isEmpty ifTrue: [ ^ #unknown ].

crCount := 0. lfCount := 0. crlfCount := 0. index := 1.

[ index <= aByteArray size ] whileTrue: [ | currentByte | currentByte := aByteArray at: index.

"Check for CRLF sequence" (currentByte = 13 and: [ index < aByteArray size and: [ (aByteArray at: index + 1) = 10 ] ]) ifTrue: [ crlfCount := crlfCount + 1. index := index + 2 ] ifFalse: [ "Check for standalone CR or LF" currentByte = 13 ifTrue: [ crCount := crCount + 1 ]. currentByte = 10 ifTrue: [ lfCount := lfCount + 1 ]. index := index + 1 ] ].

"Determine the predominant convention" result := self determineConvention: crCount lf: lfCount crlf: crlfCount. ^ result ```

FileLineEndingDetector class >> determineConvention: crCount lf: lfCount crlf: crlfCount “Determine the line ending convention based on counts”

``` | total | total := crCount + lfCount + crlfCount.

total = 0 ifTrue: [ ^ #unknown ].

"If CRLF is present and dominant, it's Windows" (crlfCount > 0 and: [ crlfCount >= (total * 0.8) ]) ifTrue: [ ^ #crlf ].

"If LF is dominant, it's Unix/Linux" (lfCount > 0 and: [ lfCount >= (total * 0.8) ]) ifTrue: [ ^ #lf ].

"If CR is dominant, it's old Mac" (crCount > 0 and: [ crCount >= (total * 0.8) ]) ifTrue: [ ^ #cr ].

"Mixed line endings detected" ^ #mixed ```

FileLineEndingDetector class >> getLineEndingInfo: aFilename “Get detailed information about line endings in a file”

``` | fileReference contents info |

fileReference := aFilename asFileReference. fileReference exists ifFalse: [ ^ Dictionary new at: #error put: 'File does not exist'; yourself ].

contents := fileReference binaryReadStream contents. info := self analyzeLineEndings: contents.

info at: #filename put: aFilename. info at: #size put: fileReference size.

^ info ```

FileLineEndingDetector class >> analyzeLineEndings: aByteArray “Analyze and return detailed information about line endings”

``` | crCount lfCount crlfCount index info |

crCount := 0. lfCount := 0. crlfCount := 0. index := 1.

[ index <= aByteArray size ] whileTrue: [ | currentByte | currentByte := aByteArray at: index.

(currentByte = 13 and: [ index < aByteArray size and: [ (aByteArray at: index + 1) = 10 ] ]) ifTrue: [ crlfCount := crlfCount + 1. index := index + 2 ] ifFalse: [ currentByte = 13 ifTrue: [ crCount := crCount + 1 ]. currentByte = 10 ifTrue: [ lfCount := lfCount + 1 ]. index := index + 1 ] ].

info := Dictionary new. info at: #cr put: crCount. info at: #lf put: lfCount. info at: #crlf put: crlfCount. info at: #total put: (crCount + lfCount + crlfCount). info at: #convention put: (self determineConvention: crCount lf: lfCount crlf: crlfCount).

^ info ```

FileLineEndingDetector class >> convertFile: aFilename to: aConvention “Convert a file to use a specific line ending convention”

``` | fileReference contents convertedContents |

fileReference := aFilename asFileReference. fileReference exists ifFalse: [ ^ self error: 'File does not exist: ', aFilename ].

contents := fileReference contents. convertedContents := self convertString: contents to: aConvention.

fileReference writeStreamDo: [ :stream | stream nextPutAll: convertedContents ].

^ true ```

FileLineEndingDetector class >> convertString: aString to: aConvention “Convert a string to use a specific line ending convention”

``` | normalized newLineString |

"First normalize to LF only" normalized := aString copyReplaceAll: String crlf with: String lf. normalized := normalized copyReplaceAll: String cr with: String lf.

"Then convert to target convention" aConvention = #lf ifTrue: [ ^ normalized ].

aConvention = #crlf ifTrue: [ newLineString := String crlf. ^ normalized copyReplaceAll: String lf with: newLineString ].

aConvention = #cr ifTrue: [ newLineString := String cr. ^ normalized copyReplaceAll: String lf with: newLineString ].

^ normalized ```

“Extension methods for FileReference”

FileReference >> detectLineEnding “Detect the line ending convention of this file” ^ FileLineEndingDetector detectLineEndingIn: self fullName

FileReference >> lineEndingInfo “Get detailed line ending information for this file” ^ FileLineEndingDetector getLineEndingInfo: self fullName

FileReference >> convertLineEndingTo: aConvention “Convert this file to use a specific line ending convention” ^ FileLineEndingDetector convertFile: self fullName to: aConvention

“Usage examples:” “ ““Basic detection”” FileLineEndingDetector detectLineEndingIn: ‘/path/to/file.txt’.

``` ""Using FileReference extension"" '/path/to/file.txt' asFileReference detectLineEnding.

""Get detailed information"" FileLineEndingDetector getLineEndingInfo: '/path/to/file.txt'.

""Convert file to Unix line endings"" '/path/to/file.txt' asFileReference convertLineEndingTo: #lf.

""Convert file to Windows line endings"" FileLineEndingDetector convertFile: '/path/to/file.txt' to: #crlf. ```

This was given with some explanations. Seems not so bad to me. It uses ByteArray. Questiona le ?

[image: image]

[image: claude_ogimage.png]

Character-Based Line Ending Detection for Pharo <https://claude.ai/public/artifacts/711cce71-a09d-4fa9-851b-cea4ae184463> claude.ai <https://claude.ai/public/artifacts/711cce71-a09d-4fa9-851b-cea4ae184463> <https://claude.ai/public/artifacts/711cce71-a09d-4fa9-851b-cea4ae184463>

https://claude.ai/public/artifacts/ed4d065b-4d66-401e-b41c-a094c8c5435c

Something, I’d like to do is using Claude Code (I used the chat here- the terminal mode hase more memory and agentic feature) with is quite mind blowing to me. Ideally, I’d like to make him ingest some good quality code or why not all the mini image code (or the VM ?).

I think there must be ways to use Claude Code efficiently (.claude stuffs, etc) that would make the writing “personalized”.

My 2 cents. Cedrick.