- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Moved out the fileIn crap to it's own object :)

by Esteban Lorenzano

great Guille! On May 5, 2012, at 2:42 AM, Guillermo Polito wrote: > Comes with tests :) (wow, fileIn tests! :P). > > It's probably not complete, because I couldn't in this two hours chase all the fileIn code, but it already reads methods, classes, class organizations, doits, class comments. > > Guille > <chunker.2.cs>

May 5, 2012

Re: [Pharo-project] [ANN] STON - Smalltalk Object Notation

by Serge Stinckwich

On Sat, May 5, 2012 at 4:02 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Hi, > > STON - Smalltalk Object Notation is a lightweight text-based, human-readable data interchange format for class-based object-oriented languages like Smalltalk. Â It can be used to serialize domain level objects, either for persistency or network transport. Â As its name suggests, it is based on JSON (Javascript Object Notation). Â It adds symbols as a primitive value, class tags for object values and references. > > Please read the paper here: > > Â Â Â Â https://github.com/svenvc/ston/blob/master/ston-paper.md > > The project lives here: > > Â Â Â Â https://github.com/svenvc/ston > > The code can be found here as well: > > Â Â Â Â http://ss3.gemstone.com/ss/STON > > This implementation works on Pharo 1.3, 1.4 and 2.0 as well as on Squeak. > > Last week Dale Henrich helped me get started with filetree/git (https://github.com/dalehenrich/filetree) and I like it. Â Check it out! Â He also ported STON to Gemstone, and is working on Amber and Cuis ports (https://github.com/dalehenrich/ston) Welcome on board ;-) Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 5, 2012

[Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by Igor Stasenko

Hi, David, all i just want to know, if we can use FFI calls, for implementing an OSProcessPlugin functionality (or at least most of it). and if there parts which is hard to implement, i would like to know what and why. If you want to ask, why one would want to do this.. the answer is simple: we stated previously, that we want to reduce the VM complexity by implementing things at language side, when it possible, leaving only key parts to VM. This is the main reason why i consider implementing OSProcess using purely FFI, not because of quality of OSProcessPlugin implementation etc. -- Best regards, Igor Stasenko.

May 5, 2012

Re: [Pharo-project] A nice replacemente for the sender sender sender sender sender sender WTF :)

by Igor Stasenko

On 5 May 2012 03:11, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 May 2012 01:06, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> I've just noticed that the following expression: >> >> Â Â Â InMidstOfFileinNotification signal ifFalse: [ ... >> >> Is to notice if I'm in the middle of the file in. >> >> > unless there is another process who InMidstOfFilein. > > IMO one should use plain boring semaphores and critical section, > because exceptions have effect on current process, but completely > ignorant to what happens > in other ones. > > just to test , add the following test: > > sema := Semaphore new. > > [ sema signal. self fileIn: '20 seconds asDelay wait' ] fork. > > sema wait. > self should: (self fileIn: '20 seconds asDelay wait') raise: oops, the above is of course should be: self should: [self fileIn: '20 seconds asDelay wait'] raise: but i think you got an idea. > InMidstOfFileInErrorOrWhatever. > >> >> >> >> >> >> >> >> >> >> >> >> amazing, >> Guille > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

May 5, 2012

Re: [Pharo-project] A nice replacemente for the sender sender sender sender sender sender WTF :)

by Igor Stasenko

On 5 May 2012 01:06, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I've just noticed that the following expression: > > Â Â Â InMidstOfFileinNotification signal ifFalse: [ ... > > Is to notice if I'm in the middle of the file in. > > unless there is another process who InMidstOfFilein. IMO one should use plain boring semaphores and critical section, because exceptions have effect on current process, but completely ignorant to what happens in other ones. just to test , add the following test: sema := Semaphore new. [ sema signal. self fileIn: '20 seconds asDelay wait' ] fork. sema wait. self should: (self fileIn: '20 seconds asDelay wait') raise: InMidstOfFileInErrorOrWhatever. > > > > > > > > > > > > amazing, > Guille -- Best regards, Igor Stasenko.

May 5, 2012

Re: [Pharo-project] Standard input in Pharo?

by Igor Stasenko

On 5 May 2012 00:46, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Guillermo Polito wrote >> >> Thanks for fixing :) >> > > Sure! > > For fun, here's a REPL using no packages added to 1.4: > [ > Â Â Â Â command := FileStream stdin nextLine. > Â Â Â Â command = 'exit' ] whileFalse: [ > Â Â Â Â Â Â Â Â result := Compiler evaluate: command. > Â Â Â Â Â Â Â Â FileStream stdout nextPutAll: result asString; lf ]. "for completeness of your example, i would add after loop: " Smalltalk snapshot: false andQuit:true. > You just have to start from a terminal... > > Sean > > -- > View this message in context: http://forum.world.st/Standard-input-in-Pharo-tp2173080p4610033.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

May 5, 2012

Re: [Pharo-project] OSProcess - is process done?

by Igor Stasenko

On 5 May 2012 02:36, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, May 4, 2012 at 5:24 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 5 May 2012 00:56, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Fri, May 4, 2012 at 3:28 PM, Igor Stasenko <siguctua(a)gmail.com> >> > wrote: >> >> >> >> On 5 May 2012 00:21, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> > >> >> > Sean P. DeNigris wrote >> >> >> >> >> >> PipeableOSProcess>>#upToEnd eventually calls >> >> >> AttachableFileStream>>#upToEnd, which tries to perform a buffered >> >> >> read >> >> >> by >> >> >> "self nextInto: 1000" (which eventually calls primitiveFileRead >> >> >> which >> >> >> calls sqFileReadIntoAt which calls fread with count arg of 1000). >> >> >> >> >> > >> >> > After further investigation, it seems to me that blocking #upToEnd is >> >> > functionally the same as #upToEndOfFile, because its test to stop >> >> > reading >> >> > data is StandardFileStream>>atEnd, which calls feof(). Therefore, if >> >> > there >> >> > is no EOF, it will keep reading until the pipe is out of data, and >> >> > then >> >> > hang >> >> > in fread on the following iteration. >> >> > >> >> imo >> >> stdin upToEnd >> >> makes no sense.. >> >> one should not expect that data which comes to stdin has any notion of >> >> "end", >> >> therefore he should never use this method on such stream. >> > >> > >> > Um, no. Â See below. >> > >> >> >> >> stdin/out are unbound (endless) streams , and use things like eof(), >> >> and other of such sort >> >> should be discouraged.. since it is same as asking >> >> infinity atEnd. >> > >> > >> > Um, no. Â One can redirect a file to stdin. Â One can type EOF to stdin. >> > EOF >> > definitely *does* make sense for stdin. >> >> what? like putc(EOF)? > > > No. Â One types an EOF character to the shell (see stty) and the shell > responds by closing the pipe to the process. Â The process then detects an > eof condition once it has read all the data from the pipe. Â There are no EOF > characters in a stream on unix. > whatever. its only a shell convention. it just closes the stream by handling input from user. if you look at general case (between two unfamiliar processes), you cannot assume anything. >> but that is a convention between two ends. if another end does not >> recognizing EOF character >> as an "end of input" signal, it will keep waiting for more data. >> since these streams are natually binary, i would be really surprised >> if some characters is reserved >> for special purposes. >> >> > Â stdin. stdout and stderr are merely >> > well-defined stream names. Â they can be bound to arbitrary streams, >> > infinite >> > or otherewise. Â In unix shells piping is built using dup with fork & >> > exec to >> > arrange that some program reads and writes to specific pipe files in a >> > full >> > pipe. >> >> right. but as you gave an example, imagine that i used dup() >> and one fork keeps writing to stream, while other closes own copy, >> do receiving side receives any "EOF" signal? i doubt. > > > Um, that's not how it is used. Â One process (e.g. parent) holds the write > end of the pipe and it can close that end. Â The other process (e.g. child) > holds teh read end and it can detect eof when it consumes all available > input. > but how you can detect end of available input if other side never closing own end? and it is free to do so. that's why i say that using upToEnd for stdin is bad practice... because i can always redirect endless stream as input for stdin .. and so your program will run in endless loop. > >> >> Here the excert from feof man page: >> Â Â The function feof() tests the end-of-file indicator for the stream >> pointed to by stream, returning non-zero if it is set. Â The >> end-of-file indicator may be cleared by explic- >> Â Â itly calling clearerr(), or as a side-effect of other operations, >> e.g. fseek(). >> >> which means that actually, eof is nothing else than error which >> captured while attempting to read moar from stream, nicely converted >> to eof() by higher abstraction level functions (fxxxx C functions). > > > Right. > >> >> >> but if you look at basic infrastructure, supported by kernel (read(), >> write()), there is no notion of "eof" for descriptors. all you can >> have is an error while attempting to read from or write to descriptor, >> and then you can decide how to handle that error by either treating it >> as end-of-file or signaling exception etc. > > > So for files, where eof is an attempt to read beyond end-of-file but not so > for pipes and socket streams there is a notion of eof, which is when all > data has been read and the write side of the pipe/socketstream is closed. > Â See pipe(2), &Â socketpair(2) but its again about handling error status. it even says so in man page: --- A pipe whose read or write end has been closed is considered widowed. Writing on such a pipe causes the writing process to receive a SIGPIPE signal. Widowing a pipe is the only way to deliver end-of-file to a reader: after the reader consumes any buffered data, reading a widowed pipe returns a zero count. --- but as you can see, for system there is still no notion of end-of-file. it is again, convention where you can assume that upon receiving SIGPIPE you meet the end of input, except from cases.. when such condition is unexpectable.. like reading from /dev/random :) one application can treat SIGPIPE as end of input, while another can treat it as "there something wrong with process, which delivering data to me", and so he will attempt to reconnect. -- Best regards, Igor Stasenko.

May 5, 2012

[Pharo-project] Moved out the fileIn crap to it's own object :)

by Guillermo Polito

Comes with tests :) (wow, fileIn tests! :P). It's probably not complete, because I couldn't in this two hours chase all the fileIn code, but it already reads methods, classes, class organizations, doits, class comments. Guille

May 5, 2012

Re: [Pharo-project] Drawing speed for animations?

by Igor Stasenko

On 5 May 2012 01:43, Martin Drautzburg <Martin.Drautzburg(a)web.de> wrote: > On Saturday, 5. May 2012 00:17:09 Igor Stasenko wrote: > >> may i ask you, what is your plans? >> say, you want to implement a particle system which can be animated at >> decent frame rate, >> or something more complex? > > No much simpler. All I am doing is some sort of gantt chart. I thought smoth- > scrolling would be cool, so I implemented it. But it just doesn't look as > smooth as an iPad (but pretty smoth nontheless) > but you can cheat. look at ipad/imac zooming interface.. when you zoom in, it doesn't redraws the whole desktop each frame. it just captures screenshoot and zooms that image instead (with nice filtering of course).. and only when you stop zooming, it redraws everything at new scale. as for you, you can do the same, you can prerender a big bitmap in memory, and show only portion of it, while scrolling. >> you know, there's always workarounds.. like in case of particles, >> instead of creating separate >> morphs for each of them, just use single morph and draw them in own >> #drawOn: method >> for morph which will represents your scene.. > > I had this idea initially too, but when I started to imangine, what I would > have to write in my drawOn: method, I ended up with pretty much the same > things, morphic is already doing. > > But actually my major concern is: do I still have a flaw in my program, i.e. > is 0.2 msec per morph an acceptable value. If so, I will stop worrying. If not > I will hunt for it. I am not complaining about morphic, I just want to know if > an experienced programmer would settle for a less than 70 Hz framerate when > moving around a few hundred Morphs? > you should keep in mind that redrawing dozens of morphs involves checking a lot of extra conditions per morph, like visibility, clipping, calculating bounds etc etc etc which costs precious cycles. and which presumably you can easily avoid by having less heavyweight model for your scene. -- Best regards, Igor Stasenko.

May 5, 2012

Re: [Pharo-project] OSProcess - is process done?

by Eliot Miranda

On Fri, May 4, 2012 at 5:24 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 May 2012 00:56, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Fri, May 4, 2012 at 3:28 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 5 May 2012 00:21, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> > > >> > Sean P. DeNigris wrote > >> >> > >> >> PipeableOSProcess>>#upToEnd eventually calls > >> >> AttachableFileStream>>#upToEnd, which tries to perform a buffered > read > >> >> by > >> >> "self nextInto: 1000" (which eventually calls primitiveFileRead which > >> >> calls sqFileReadIntoAt which calls fread with count arg of 1000). > >> >> > >> > > >> > After further investigation, it seems to me that blocking #upToEnd is > >> > functionally the same as #upToEndOfFile, because its test to stop > >> > reading > >> > data is StandardFileStream>>atEnd, which calls feof(). Therefore, if > >> > there > >> > is no EOF, it will keep reading until the pipe is out of data, and > then > >> > hang > >> > in fread on the following iteration. > >> > > >> imo > >> stdin upToEnd > >> makes no sense.. > >> one should not expect that data which comes to stdin has any notion of > >> "end", > >> therefore he should never use this method on such stream. > > > > > > Um, no. See below. > > > >> > >> stdin/out are unbound (endless) streams , and use things like eof(), > >> and other of such sort > >> should be discouraged.. since it is same as asking > >> infinity atEnd. > > > > > > Um, no. One can redirect a file to stdin. One can type EOF to stdin. > EOF > > definitely *does* make sense for stdin. > > what? like putc(EOF)? > No. One types an EOF character to the shell (see stty) and the shell responds by closing the pipe to the process. The process then detects an eof condition once it has read all the data from the pipe. There are no EOF characters in a stream on unix. but that is a convention between two ends. if another end does not > recognizing EOF character > as an "end of input" signal, it will keep waiting for more data. > since these streams are natually binary, i would be really surprised > if some characters is reserved > for special purposes. > > > stdin. stdout and stderr are merely > > well-defined stream names. they can be bound to arbitrary streams, > infinite > > or otherewise. In unix shells piping is built using dup with fork & > exec to > > arrange that some program reads and writes to specific pipe files in a > full > > pipe. > > right. but as you gave an example, imagine that i used dup() > and one fork keeps writing to stream, while other closes own copy, > do receiving side receives any "EOF" signal? i doubt. > Um, that's not how it is used. One process (e.g. parent) holds the write end of the pipe and it can close that end. The other process (e.g. child) holds teh read end and it can detect eof when it consumes all available input. > Here the excert from feof man page: > The function feof() tests the end-of-file indicator for the stream > pointed to by stream, returning non-zero if it is set. The > end-of-file indicator may be cleared by explic- > itly calling clearerr(), or as a side-effect of other operations, > e.g. fseek(). > > which means that actually, eof is nothing else than error which > captured while attempting to read moar from stream, nicely converted > to eof() by higher abstraction level functions (fxxxx C functions). > Right. > > but if you look at basic infrastructure, supported by kernel (read(), > write()), there is no notion of "eof" for descriptors. all you can > have is an error while attempting to read from or write to descriptor, > and then you can decide how to handle that error by either treating it > as end-of-file or signaling exception etc. > So for files, where eof is an attempt to read beyond end-of-file but not so for pipes and socket streams there is a notion of eof, which is when all data has been read and the write side of the pipe/socketstream is closed. See pipe(2), & socketpair(2) > > > >> > >> > -- > >> > View this message in context: > >> > > http://forum.world.st/OSProcess-is-process-done-tp4569088p4609991.html > >> > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

May 5, 2012