March 2019 - Pharo-users - lists.pharo.org

planet.smalltalk.org

by Pierce Ng

I deleted the earlier thread from my mailbox, so starting a new one. By chance I found http://prog.vub.ac.be/~cderoove/planet/ which is the Planet Smalltalk aggregator hosted by Coen De Roover. It is still running and has the latest entries. Just a bit more work is needed to get planet.smalltalk.org to once again point to this aggregator. Pierce

March 9, 2019

Re: [Pharo-users] Pharo 7.0 image size

by Hilaire

Hi, Beside the browser windows, did you close all Transcript windows? Hilaire Le 08/03/2019 Ã 11:59, Trussardi Dario Romano a Ã©critÂ : > Ciao, > > this morning i started with an image of about 240 MB. > > I have 3 System Browser open ( for a long time ). -- Dr. Geo http://drgeo.eu

March 9, 2019

pharo launcher chrash

by Roelof Wobben

Hello, When starting up the launcher on Windows 10 I see a crash. A dmp file is included. Roelof

March 9, 2019

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

by Sven Van Caekenberghe

Konrad, You are raising many different points, I'll try to answer them. But first, it would help a lot that you give a self-contained reproducible snippet that raises your problem, like mine. I tried reproducing your failure but could not. Also note that all FUEL tests are green on a recent Pharo image. Regarding architecture and design. The idea of the 'new' streams is about simplification, streamlining and composability (if this is a real word) based on separation of concerns. It is my strong opinion that the current stream API is way to broad and complex. That is the main reason why it is not or should not be necessary to inherit from Stream. We want read and write streams to be separate, we want binary and character streams to be separate. Buffering, line end conversions, etc, should be pluggable. I remember that FLBufferedWriteStream was actual based on ZnBufferedWriteStream (one of FUEL's goals is performance), at a time when the primitive binary streams were unbuffered. That was years ago. Today, the high level binary streams are in principle buffered (ZnBufferedWriteStream) (although the raw ones still exist). It is thus no longer necessary to use FLBufferedWriteStream (although its API is slightly larger, it does a bit more than just buffer output). Now, looking at the specific selector you are talking about, #nextBytesPutAll: the way it is implemented and used, I can't understand why it even exists. Unless I am missing something it is the same as #nextPutAll: It is probably related to backwards or cross platform compatibility. Because today in Pharo, given a (buffered) binary stream, #nextPutAll: always takes bytes as argument. Another point is that right now, it seems double buffering is happening, which is not good. I guess we'll have to wait for one of the FUEL developers to chime in. All this being said, we are still in a transition period. Sven > On 9 Mar 2019, at 10:08, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > 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

Pharo OSX bundle in Mojave - how to sign ? (Was Re: OS X bundle, some progress)

by CÃ©drick BÃ©ler

Hi, I tried a bit more to make DrGeo bundle works. I have Mojave (10.14) and the problem of corrupted files seems to come from Gatekeeper with prevent unsigned applications (from unknot developper) to open. Gatekeeper can be temporary stopped and then the bundle work, even when Gatekeeper is reactivated. But clearly, this is not a friendly user way of installing DrGeo. So I guess the actual (old ?) bundle procedure doesnât fit Apple politic on application security. I'm pretty sure PharoLauncher faced this already. So my question is: - how to make a signed bundle for OSX ? â do we need a real developer account ? Iâve a free one and access to a paid one. Can we do it with a general Â« pharaoh Â» account like for Pharo-Launcher ? Cheers, CÃ©drick > Le 3 mars 2019 Ã 15:59, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > > Hi Hilaire, > > On Sun, 3 Mar 2019 at 09:31, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> One useful information will be to know where stdout file is created by >> default? >> >> VM, image, home, folder, ... > > On linux and MacOS the three stdio streams exist for every process: > stdin, stdout & stderr. > > If you're starting a process from the shell, they are normally > attached to the terminal (unless you redirect them). I don't know > what happens on MacOS when you start a process from the GUI. > > >> Obviously there is situation with problem creating stdout files. > > There's lots of MacOS users here who aren't having this problem, so my > first guess is that there's something about your environment that is > causing the issue. > > Can you provide the text from System -> System Reporter -> VM General? > > Cheers, > Alistair > > >> Can it be shutdown? >> >> For the record, the error is REPEATABLE, Pharo started from the CLI or >> from an installed Application. Once the image started: >> >> error with stdout does not exist, force recursive file creation, filename "stdout" >> >> This occures with stock OS X 32bits VM and Image. >> >> Any one willing to do serious deliverable Pharo Application with Mac >> will be hit by this error. Is OS X making situation more difficult? >> >> Hilaire >> >> Le 01/03/2019 Ã 23:19, Hilaire a Ã©crit : >> Hi, >>> I did some progress on the Dr.Geo bundle for OS X. >>> >>> The Mac admin of my school told me to download from Safari and >>> authorized the drgeo.eu web site (not sure what this exactly does), then >>> we installed the DrGeo.app at the Application location. >>> >>> DrGeo started fine but emit a startup error at the image level, related >>> to stdout. It looks like a stdout file can not be created. The stack is >>> enclosed here. When looking at the execution stack, I could not >>> determine (I have to go teaching) where the image wants to create this >>> stdout file. >>> >>> Any idea or opinion on this stdout matter? >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >

March 9, 2019

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