- Pharo-users - lists.pharo.org

Re: [Pharo-users] FUEL serialization to a file

by Konrad Hinsen

Am 09.03.19 um 08:16 schrieb Konrad Hinsen: > In the second line, it sends nextBytesPutAll: to the unbuffered > stream. Which should be fine if it inherits from Stream. But > ZnBufferedWriteStream does not inherit from Stream. The fix I found is simple, but I don't understand the whole system well enough to be sure that it doesn't cause trouble elsewhere. I added the method ZnBufferedWriteStream >> nextBytesPutAll: nextBytesPutAll: aCollection self nextPutAll: aCollection and all my problems are gone. Konrad.

March 9, 2019

Re: [Pharo-users] FUEL serialization to a file

by Konrad Hinsen

Sven Van Caekenberghe <sven(a)stfx.eu> writes: > FUEL is a binary serialiser, in the new Pharo 7 stream approach, a > stream is either binary or textual, not both, nor can they be switched > on the fly. OK, thanks for confirming my suspicion that there was a change in Pharo. > FileLocator temp / 'test.fuel' binaryWriteStreamDo: [ :out | FLSerializer newDefault serialize: { 'Foo'. #bar. Float pi. 42 } on: out ]. So what I have been using is correct. Tim Mackinnon <tim(a)testit.works> writes: > Hmmm - yesterday I had someone serialise their debug stack (the top > right menu bar action) to a file and send it to me and it worked treat > - so I wonder what the difference is? The problem I have occurs in buffering code. I suspect that it happens as a function of the size distribution of the objects that are serialized. The problem is best analyzed by looking at the implementors of #nextBytesPutAll:. That's an extension method that Fuel puts on the Stream hierarchy, including its own class FLBufferedWriteStream where the method contains the lines collection size > (self buffer size / 2) ifTrue: [ stream nextBytesPutAll: collection ] ifFalse: [ self nextBytesPutAll: collection ] In the second line, it sends nextBytesPutAll: to the unbuffered stream. Which should be fine if it inherits from Stream. But ZnBufferedWriteStream does not inherit from Stream. I tried unraveling the construction of ZnBufferedWriteStream, to use directly its underlying stream: | ref stream | ref := FileLocator temp / 'test.fuel'. stream := ref fileSystem binaryWriteStreamOn: ref path. [ FLSerializer newDefault serialize: { 'Foo'. #bar. Float pi. 42 } on: stream ] ensure: [ stream close ] On a standard file, that yields a BinaryFileStream, and everything works fine. But for my test cases I use a MemoryFileSystem, and then I get the same problem again - MemoryFileWriteStream does not inherit from Stream either. I wonder what's wrong with the Stream class - why are there stream-type classes that don't inherit from it? Konrad.

March 9, 2019

Re: [Pharo-users] FUEL serialization to a file

by Sven Van Caekenberghe

FUEL is a binary serialiser, in the new Pharo 7 stream approach, a stream is either binary or textual, not both, nor can they be switched on the fly. FileLocator temp / 'test.fuel' binaryWriteStreamDo: [ :out | FLSerializer newDefault serialize: { 'Foo'. #bar. Float pi. 42 } on: out ]. FileLocator temp / 'test.fuel' binaryReadStreamDo: [ :in | (FLMaterializer newDefault materializeFrom: in) root ]. > On 8 Mar 2019, at 21:22, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Hi everyone, > > after playing with FUEL in-memory (byte arrays) for a while, I am ready > to attack files. But... that's not so easy. > > At > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > I find the basic exxample > > 'demo.fuel' asFileReference writeStreamDo: [ :aStream | > FLSerializer newDefault > serialize: 'stringToSerialize' > on: aStream binary ]. > > It fails because ZnCharacterWriteStream does not understand #binary. > > Browsing around a bit, I found another way: > > 'demo.fuel' asFileReference writeStreamDo: [ :aStream | > FLSerializer newDefault > serialize: 'stringToSerialize' > on: aStream binary ]. > > This works fine, the aStream being a ZnBufferedWriteStream. But on > larger objects, it ends up failing in > > FLBufferedWriteStream >> #nextBytePutAll: > > which sends the message > > stream nextBytesPutAll: collection > > But ZnBufferedWriteStream does not understand nextBytesPutAll: because > it is not a subclass of Stream for whatever reason. > > Some further browing showed deprecated classes FileStream etc., and I > kind of suspect that file streams in Pharo were changed at some point > but FUEL still expects the old behavior. > > Does anyone have an idea how to fix this, or work around it? > > Thanks in advance, > Konrad >

March 8, 2019

Re: [Pharo-users] FUEL serialization to a file

by Tim Mackinnon

Hmmm - yesterday I had someone serialise their debug stack (the top right menu bar action) to a file and send it to me and it worked treat - so I wonder what the difference is? Tim Sent from my iPhone > On 8 Mar 2019, at 20:22, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Hi everyone, > > after playing with FUEL in-memory (byte arrays) for a while, I am ready > to attack files. But... that's not so easy. > > At > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > I find the basic exxample > > 'demo.fuel' asFileReference writeStreamDo: [ :aStream | > FLSerializer newDefault > serialize: 'stringToSerialize' > on: aStream binary ]. > > It fails because ZnCharacterWriteStream does not understand #binary. > > Browsing around a bit, I found another way: > > 'demo.fuel' asFileReference writeStreamDo: [ :aStream | > FLSerializer newDefault > serialize: 'stringToSerialize' > on: aStream binary ]. > > This works fine, the aStream being a ZnBufferedWriteStream. But on > larger objects, it ends up failing in > > FLBufferedWriteStream >> #nextBytePutAll: > > which sends the message > > stream nextBytesPutAll: collection > > But ZnBufferedWriteStream does not understand nextBytesPutAll: because > it is not a subclass of Stream for whatever reason. > > Some further browing showed deprecated classes FileStream etc., and I > kind of suspect that file streams in Pharo were changed at some point > but FUEL still expects the old behavior. > > Does anyone have an idea how to fix this, or work around it? > > Thanks in advance, > Konrad >

March 8, 2019

FUEL serialization to a file

by Konrad Hinsen

Hi everyone, after playing with FUEL in-memory (byte arrays) for a while, I am ready to attack files. But... that's not so easy. At https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… I find the basic exxample 'demo.fuel' asFileReference writeStreamDo: [ :aStream | FLSerializer newDefault serialize: 'stringToSerialize' on: aStream binary ]. It fails because ZnCharacterWriteStream does not understand #binary. Browsing around a bit, I found another way: 'demo.fuel' asFileReference writeStreamDo: [ :aStream | FLSerializer newDefault serialize: 'stringToSerialize' on: aStream binary ]. This works fine, the aStream being a ZnBufferedWriteStream. But on larger objects, it ends up failing in FLBufferedWriteStream >> #nextBytePutAll: which sends the message stream nextBytesPutAll: collection But ZnBufferedWriteStream does not understand nextBytesPutAll: because it is not a subclass of Stream for whatever reason. Some further browing showed deprecated classes FileStream etc., and I kind of suspect that file streams in Pharo were changed at some point but FUEL still expects the old behavior. Does anyone have an idea how to fix this, or work around it? Thanks in advance, Konrad

March 8, 2019

Re: [Pharo-users] NeoCSV Logging

by Sven Van Caekenberghe

You mean something like signal progress notifications ? No that does not exist, indeed you can roll your own, counting every record read and then do something every N times. > On 8 Mar 2019, at 20:29, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Is there anything built-in? I have a particularly long file and want to give > updates so users don't thing the image has frozen. > > If not, thinking I'll subclass reader and override #do: > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

March 8, 2019

NeoCSV Logging

by Sean P. DeNigris

Is there anything built-in? I have a particularly long file and want to give updates so users don't thing the image has frozen. If not, thinking I'll subclass reader and override #do: ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 8, 2019

Re: [Pharo-users] Alternative to NautilusMethodSelected in Calypso

by HernÃ¡n Morales Durand

Hi Gustavo, Is MacroRecorder available for Pharo 7? Cheers, HernÃ¡n El mar., 4 dic. 2018 a las 14:47, Gustavo Santos (<gugajansen(a)gmail.com>) escribiÃ³: > > Hello, > > I'm trying to upgrade MacroRecorder to Pharo7. > I used NautilusClassSelected and NautilusMethodSelected announcements to apply a macro in a given class or method right after the developer clicks on the browser. Something like > > AbstractNautilusPlugin subclass: #MRNautilusPlugin ... > > registerTo: aModel > aModel announcer weak > when: NautilusClassSelected send: #entitySelected: to: self; > when: NautilusMethodSelected send: #entitySelected: to: self. > > How can I do the same with Calypso? > > Cheers, > -- > Gustavo Santos > http://gustavojss.github.io/

March 8, 2019

Re: [Pharo-users] ldap, Pier3 & git migration

by Ben Coman

On Fri, 8 Mar 2019 at 22:59, Albrecht Baur via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > sorry for double posting in dev and users ... > > I pushed it to > > https://github.com/pharo-contributions/LDAP > > There it fits better (and we have the 'pharo' at least inside the path...) > The case to cater for is the common action of someone forking it under their account. e.g. https://github.com/bencoman/LDAP is a bit misleading. Better to be https://github.com/bencoman/pharo-ldap cheers -ben > Best > > Albrecht > On 08.03.19 15:05, Esteban Maringolo wrote: > > I wasn't aware of LDAP support in Pharo. Thanks for porting it. > > Wouldn't it be better to call the repo "pharo-ldap"? > > When my repositories are Pharo specific and don't have a fancy project > name I name them "pharo-something", e.g. "pharo-couchdb", "pharo-base58", > "pharo-bip39mnemonic", etc. > > Regards, > > Esteban A. Maringolo > > > El vie., 8 mar. 2019 a las 8:45, Albrecht Baur via Pharo-users (< > pharo-users(a)lists.pharo.org>) escribiÃ³: > >> Hi, In case someone can use it: I used Peters git migration tool for ... >> http://smalltalkhub.com/#!/~PharoExtras/LDAP/ >> ... and put it to: >> https://github.com/a2b-alb/PharoExtras-LDAP >> >> I don't know if this is the right place or if you would rather have it >> under ... >> https://github.com/pharo-contributions/ >> ... or somewhere else. >> >> ------------- here the question: >> I started trying to do the same migration process for ... >> http://www.smalltalkhub.com/#!/~Pier/Pier3 >> ... but I failed on errors loading older mcz files: >> >> "instance of ByteString did not understand #peek" >> on: MCMczReader >> contentsForMember: >> (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) >> >> Is this wrong encoding or corrupted files ? >> How to treat these files ? -> Is just ignoring this majority of failing >> mcz files via migration ignoredFileNames: #() >> ok ? >> >> ------------- >> As a workaround I then left the history versions behind and took only >> the newest mcz files. But I am not sure which package version "is in >> harmony" with the other ones... ;-) >> -> While trying out which versions of the ConfigurationOfPier3 load in a >> p7 image only the #stable one loaded without problems. The newer ones >> didn't. >> >> I did this by first loading as much pier3 dependencies (seaside, >> magritte, ...) from the new github repos. So I can then say ... >> onConflict: [ :e | e useLoaded ]; >> ... when loading pier3 from smaltalkhub. >> >> Can someone who knows pier3 better than me, give me a hint on which >> package versions combinations are the ones to go with ? >> -> Is to just start with the newest mcz files the way to go? Or should I >> use the #stable ConfigurationOfPier3 ? >> >> best, >> Albrecht >> >> >>

March 8, 2019

Re: [Pharo-users] Read and parse maildir (offlineimap) files

by Thierry Goubier

It's a common shell script lab assignment to be able to parse this format (RFC 822). Unix 101 level. A bit tricky in practice, because the format has a strong dependency on the blank line between the header part and the email content... Technically, maildir only refers to the directory/files organisation, not the format of an email inside each file. Emails with attachments can create headaches for quick and dirty scan, because they appear as text files containing binary data a few MBs long... If you happen to have a backtracking RE or parser on it, you'll kill your image. Thierry Le ven. 8 mars 2019 Ã 16:23, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > > Hi CÃ©drick, > > On Fri, 8 Mar 2019 at 16:12, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > > > Hi Alistair, > > > > This looks like what Iâd like to have (parsing emails). Iâd better like an IMAP Client but using offlinmap might be an option. > > > > Will look at it. > > > > Do you have an exemple of milder format files ? > > Attached is the email you sent. > > I found https://github.com/codeZeilen/SMailDir but it is written for > Squeak and doesn't load cleanly in Pharo (I haven't actually done > anything with it yet). > > Cheers, > Alistair > > > > > Le 8 mars 2019 Ã 15:49, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > > > > > > Hi Everyone, > > > > > > I'd like to be able to parse and read the mail files as saved by > > > offlineimap, i.e. in maildir format (one message per file). > > > > > > Does anyone know of any existing libraries in Pharo? > > > > > > Thanks very much, > > > Alistair > > > > > > >

March 8, 2019