- Pharo-dev - lists.pharo.org

Default line endings while writing to a file stream

by Ben Coman

I'm on Windows wanting to write a text file with LF endings. The code developed on Linux is thus... (destinationDirectory / 'README.md') ensureCreateFile writeStreamDo: [ :stream | stream nextPutAll: class comment ] and I am stuck with CR line endings. The specific symptom is that it screws `git diff` Here is a simple experiment... testfile := 'README.md' asFileReference. testfile ensureCreateFile writeStreamDo: [ :stream | stream nextPutAll: 'aa bb' ]. testfile binaryReadStream contents at: 3 "==> Character cr " I think its safe to assume on Linux that will result in "==> Character lf " but can someone please confirm? So my issue is that I've got #ensureCreateFile - returns a FileReference and :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream wrapping BinaryFileStream. and neither seem to have an easily accessible defaultLineEnding setting. Indeed, line endings are not a property of FileReference and Binary & Characters have nothing to do with line endings, and questionable if Buffering is related. Its more a property of a File, but IIUC that is being deprecated (??) MultiByteFileStream has #lineEndConvention: but IIUC that also is being deprecated. So what is the proper way to force default line endings? ------ Now while composing this email I discovered String>>withUnixLineEndings. So I have a solution... testfile := 'README.md' asFileReference. testfile ensureCreateFile writeStreamDo: [ :stream | stream nextPutAll: 'aa bb' withUnixLineEndings ]. (testfile binaryReadStream contents at: 3) asCharacter "==> Character lf " but that seems to imply that on Windows... 'aa bb' at: 3 "==> Character cr " and on Linux (someone please confirm)... 'aa bb' at: 3 "==> Character lf " and that is *very* curious. Strange that I never noticed it before and obviously that hasn't hurt me, but considering the Principal Of Least Surprise it leaves me feeling somewhat violated :)

May 31, 2019

Re: [Pharo-dev] Smalltalk to Smalltalk interface

by askoh

What is the means of communication used between VW and Pharo to pass STON files as objects? I would like something where VW starts up Pharo and asks Pharo to do something that is not available in VW and pass back the answers. I think all the Smalltalk dialects should be able to call each other with easy to attain the union of all the capabilities of Smalltalk dialects. No need to port one dialect to another but to collaborate in execution. Thanks for replies, Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 31, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Ben Coman

On Fri, 31 May 2019 at 09:09, Shaping <shaping(a)uurda.org> wrote: > Thanks for the explanation, Ben. This isnât good for the future of > Pharo. > Could you expand your thoughts on that? I don't see why. Linux didn't fall apart with the introduction of... tar, rpm, yum, apt, dnf, etc... What a headache. > I don't find it so. What is the headache for you? is it confusion about the scope of each? Maybe we need to better communicate this? Has anyone investigated automatic scripted conversion of Monticello > formats to Iceberg with Git? > I believe there has been some work. If no better answers come, search http://forum.world.st/ I donât see how this will ever be done or finished manually, humans being > what they are. > What you a promoting is forcing a monoculture. Humans being what they are, don't respond well to that. The fragmented versioning-technologies will persist then indefinitely. > Iceberg/git in only been in broad use for one year since release of Pharo 7. How fast do you expect the world to change? The diffusion of innovation applies... https://en.wikipedia.org/wiki/Diffusion_of_innovations Some people work in multiple Smalltalk versions that continue to use Monticello (http://www.squeaksource.com) and want to maintain a cross-platform package. So even with the most perfect conversion script, Monticello will remain an option. The alternative scenario of having only one versioning system would have been to stick with Monticello and avoid using git. I don't consider that viable. I believe Pharo has a great future with a preferred option going forward with Git and an option to access legacy code with Monticello. cheers -ben > > > > > Shaping > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Ben Coman > *Sent:* Thursday, May 30, 2019 08:45 > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] FW: Versioning with Iceberg > > > > On Thu, 30 May 2019 at 18:56, Shaping <shaping(a)uurda.org> wrote: > > > > I prefer to use one tool for versioning. Is that possible now in any > version of Pharo? Can I use only Iceberg for all fetches and all > commits? Or must I sometimes use evaluables like: > > > > Metacello new > > baseline: 'Exercism'; > > repository: 'github://exercism/pharo-smalltalk/releases/latest'; > > onConflict: [ :ex | ex allow ]; > > load. > > > > Metacello operates at a higher level than Iceberg. > > Iceberg (like Monticello) versions individual packages. > > Metacello defines the version dependencies between packages, including > different git repos and Monticello repos. > > The Metacello definition is versioned like any other code, using either > Iceberg or Monticello. > > > I'm not completely sure, but I think Metacello uses Iceberg to load from > github repos, > so what that last code snippet does is... > Metacello loads the given baseline from github using Iceberg and parses it, > > then loads all the dependent baselines from their respective repos using > Iceberg or Monticello per the format they are stored in, > > then loads all the specified code versions using Iceberg or Monticello as > appropriate. > > > > Also once you've loaded an Iceberg repo containing a Metacello baseline, > you can invoke that baseline from within Iceberg. > > [image: image.png] > > > > Essentially Iceberg replaces Monticello for git repos, > > but there is a wealth of historical packages in Monticello format, so its > not disappearing either. > > > > HTH, > > cheers -ben > > >

May 31, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Shaping

Thanks for the explanation, Ben. This isnât good for the future of Pharo. What a headache. Has anyone investigated automatic scripted conversion of Monticello formats to Iceberg with Git? I donât see how this will ever be done or finished manually, humans being what they are. The fragmented versioning-technologies will persist then indefinitely. Shaping From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Thursday, May 30, 2019 08:45 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] FW: Versioning with Iceberg On Thu, 30 May 2019 at 18:56, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: I prefer to use one tool for versioning. Is that possible now in any version of Pharo? Can I use only Iceberg for all fetches and all commits? Or must I sometimes use evaluables like: Metacello new baseline: 'Exercism'; repository: 'github://exercism/pharo-smalltalk/releases/latest'; onConflict: [ :ex | ex allow ]; load. Metacello operates at a higher level than Iceberg. Iceberg (like Monticello) versions individual packages. Metacello defines the version dependencies between packages, including different git repos and Monticello repos. The Metacello definition is versioned like any other code, using either Iceberg or Monticello. I'm not completely sure, but I think Metacello uses Iceberg to load from github repos, so what that last code snippet does is... Metacello loads the given baseline from github using Iceberg and parses it, then loads all the dependent baselines from their respective repos using Iceberg or Monticello per the format they are stored in, then loads all the specified code versions using Iceberg or Monticello as appropriate. Also once you've loaded an Iceberg repo containing a Metacello baseline, you can invoke that baseline from within Iceberg. Essentially Iceberg replaces Monticello for git repos, but there is a wealth of historical packages in Monticello format, so its not disappearing either. HTH, cheers -ben

May 31, 2019

Re: [Pharo-dev] Crashing in Windows 10... libssh2-1.dll

by Ben Coman

Looks like you have the tools to isolate the problem. Would you like to be coached through building your own debug-vm to help track down whats happening? cheers -ben On Fri, 31 May 2019 at 02:04, casimiro barreto <casimiro.barreto(a)gmail.com> wrote: > Happens in Cog never mind image. During load of Seaside3 (never mind) > [image: image.png] >

May 30, 2019

Re: [Pharo-dev] Versioning with Iceberg

by Tim Mackinnon

> On 30 May 2019, at 11:55, Shaping <shaping(a)uurda.org> wrote: > > 7.0.3. It loaded after a fresh clone of pharo, but with a detached head. So are you trying to actually contribute to Pharo? You donât normally need to reload pharo (if Iâve understood what you are doing). I think ben has raised a bug for you for that. However, back to your other question - I had misunderstood - actually you can load specific project (like exercism) via Iceberg (although a metacello script is often more convenient - and sometimes more precise) - if you pick Add, then choose GitHub, then enter the owner and project (e.g. for exercism - owner = exercism, project = pharo-smalltalk), this will get you the baseline (but wonât load any packages). Now you have to right click on the repository, and pick the Metacello menu item, and then you can load baseline (which gives you the default), or you can enter a group name (e.g. âdevâ for exercism). If you want a different version than master, then have to open the repository view (cmd-r), there you can select a tag to load, and then you can use the metecallo menu. You can also (although somewhat painfully), right click on all the packages in a repository and select âloadâ to do them one by one. Hope this helps. Tim

May 30, 2019

Crashing in Windows 10... libssh2-1.dll

by casimiro barreto

Happens in Cog never mind image. During load of Seaside3 (never mind) [image: image.png] -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions.

May 30, 2019

Re: [Pharo-dev] Smalltalk to Smalltalk interface

by Dale Henrichs

On 5/30/19 11:09 AM, ducasse wrote: > I know that people some people ported STON to VW and used it to be able to build nice new > systems in Pharo while talking to their old software in VW. > So this is a nice way to migrate :) STON has also been ported to GemStone and likely to be ported to VA as well ... > > Stef > >> On 30 May 2019, at 12:31, askoh <askoh(a)askoh.com> wrote: >> >> Hi: >> >> While working on VisualWorks-Python interface, it occurred to me why not >> have VisualWorks-Pharo interface too. >> Has something like that been attempted? One Smalltalk dialect to Another >> Smalltalk dialect interface? >> What would be a good way to interface them? Master-Slave? Peer to Peer? >> >> Thanks, >> Aik-Siong Koh >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > >

May 30, 2019

Re: [Pharo-dev] Smalltalk to Smalltalk interface

by ducasse

I know that people some people ported STON to VW and used it to be able to build nice new systems in Pharo while talking to their old software in VW. So this is a nice way to migrate :) Stef > On 30 May 2019, at 12:31, askoh <askoh(a)askoh.com> wrote: > > Hi: > > While working on VisualWorks-Python interface, it occurred to me why not > have VisualWorks-Pharo interface too. > Has something like that been attempted? One Smalltalk dialect to Another > Smalltalk dialect interface? > What would be a good way to interface them? Master-Slave? Peer to Peer? > > Thanks, > Aik-Siong Koh > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

May 30, 2019

Smalltalk to Smalltalk interface

by askoh

Hi: While working on VisualWorks-Python interface, it occurred to me why not have VisualWorks-Pharo interface too. Has something like that been attempted? One Smalltalk dialect to Another Smalltalk dialect interface? What would be a good way to interface them? Master-Slave? Peer to Peer? Thanks, Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 30, 2019