November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Breaking PDF into smaller PDFs

by askoh

Thanks everyone for helping. I found VisualWorks PDF4Smalltalk to be perfect for me. The author Christian Haider was most helpful too. He has a successful business using it. Pharo will benefit greatly having a port. https://gitorious.org/pdf4smalltalk http://www.freelists.org/list/pdf4st See my post on VisualWorks forum http://forum.world.st/Breaking-PDF-into-smaller-PDFs-td4655116.html#a4655655 Aik-Siong Koh -- View this message in context: http://forum.world.st/Breaking-PDF-into-smaller-PDFs-tp4655015p4655656.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 17, 2012

Re: [Pharo-project] nonblocking stdin?

by Sean P. DeNigris

Pavel Krivanek-3 wrote > Is there a way how to use nonblocking input from stdin? Not sure if this helps, but this works out of the box on 2.0 (see https://gist.github.com/2604215) > | command | > [ > command := FileStream stdin nextLine. > command ~= 'exit' ] whileTrue: [ | result | > result := Compiler evaluate: command. > FileStream stdout nextPutAll: result asString; lf ]. > > Smalltalk snapshot: false andQuit: true. On 1.3 or 1.4, file in https://gist.github.com/2602113 first: > 'From Pharo2.0a of ''18 April 2012'' [Latest update: #20041] on 3 May 2012 > at 10:45:48 pm'! > > !FileStream class methodsFor: 'stdio' stamp: 'SeanDeNigris 5/3/2012 > 22:37'! > stdin > > ^Stdin ifNil: [ > Stdin := self standardIOStreamNamed: #stdin forWrite: false. > Stdin > disableReadBuffering; > yourself ].! ! -- View this message in context: http://forum.world.st/nonblocking-stdin-tp4654956p4655653.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 16, 2012

Re: [Pharo-project] about sharing class binding and others

by Marcus Denker

On Nov 16, 2012, at 8:02 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Nov 16, 2012, at 6:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> While I love the idea of sharing the systemDictionary class binding in the method to gain immediate update in case of >> change I was questioning myself if we could not gain from not having (for example to get parametrized modules). >> >> The point is that we are not constantly changing classes especially when not programming but running program. >> > > > The alternative to the current scheme would be to not hard-code the class at all in the method at compile time. > > Instead of looking up the class and compiling the shared literal association, we could compile a message send > to the current environment. > > self class environment at: #NameOfClass > > And it should be noted that this could be evaluated at Jit-compile time... the same is true for ivar offsets. There > is no reason why these should be visible at the image level. The image could talk about names and let the runtime > translator infrastucture do the lookups needed for making a static version that is fast. > And it should be noted that we don't loose anything: -> Undeclareds would disappear. Using non-existing classes leads to a runtime error, like sending non-existing messages. -> It would be slower in the pure-interpreter case. But anyone who knows me knows that I want to get rid of bytecode as a user-visible artefact... this means, the interpreter would either be an AST interpreter or it would "JIT" the AST into the virtual processor instructions before running. So: the way to go. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2012

Re: [Pharo-project] Enabling Halos

by Sean P. DeNigris

kilon wrote > I really miss halos from squeak In Pharo 2.0, the two-way cycling (i.e. the way it was in Squeak) can be restored via "Morph cycleHalosBothDirections: true." If you really want to do it in 1.4, let me know and I'll dig up the hack... Cheers, Sean -- View this message in context: http://forum.world.st/Enabling-Halos-tp4653588p4655650.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 16, 2012

Re: [Pharo-project] about sharing class binding and others

by Marcus Denker

On Nov 16, 2012, at 6:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > While I love the idea of sharing the systemDictionary class binding in the method to gain immediate update in case of > change I was questioning myself if we could not gain from not having (for example to get parametrized modules). > > The point is that we are not constantly changing classes especially when not programming but running program. > The alternative to the current scheme would be to not hard-code the class at all in the method at compile time. Instead of looking up the class and compiling the shared literal association, we could compile a message send to the current environment. self class environment at: #NameOfClass And it should be noted that this could be evaluated at Jit-compile time... the same is true for ivar offsets. There is no reason why these should be visible at the image level. The image could talk about names and let the runtime translator infrastucture do the lookups needed for making a static version that is fast. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2012

Re: [Pharo-project] new command line option: printVersion

by Marcus Denker

On Nov 16, 2012, at 7:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I was wondering how the addition of options is managed. > I mean how we know that we got what we really should have as option on the command line? > That is a good question. In the end I want the command line API mirror to some extend the API of Image objects (which we don't have yet but will have eventually). So what is the API of an image reified as an object? The main client is the build server... so the idea is to add just what we need to manipulate images "from the outside" which is in this case the command line. We should always ask if it is really needed. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2012

Re: [Pharo-project] [update 2.0] #20403

by Marcus Denker

On Nov 16, 2012, at 7:44 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Nov 16, 2012, at 7:30 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> I really like the idea of the errorNode. >> > > This is needed to replace the ad-hoc parser that is in the syntax highlighting. > With the error nodes, we can just use the same parser and implement syntax > highlighting as a normal visitor on the standard AST. > > See > > http://code.google.com/p/pharo/issues/detail?id=6893 > With the error node, it would even be possible to generate code for faulty methods, raising the syntax error again at runtime ;-) Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2012

Re: [Pharo-project] [update 2.0] #20403

by Marcus Denker

On Nov 16, 2012, at 7:30 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I really like the idea of the errorNode. > This is needed to replace the ad-hoc parser that is in the syntax highlighting. With the error nodes, we can just use the same parser and implement syntax highlighting as a normal visitor on the standard AST. See http://code.google.com/p/pharo/issues/detail?id=6893 (later we can even replace the RBParser by one implemented in PetitParser) Marcus > Stef > > > On Nov 16, 2012, at 8:08 PM, Marcus Denker wrote: > >> 20403 >> ----- >> >> Issue 6989: Move DebuggerMethodMap to Compiler package >> http://code.google.com/p/pharo/issues/detail?id=6989 >> >> Issue 6988: Run #cleanUpForRelease in postscript >> http://code.google.com/p/pharo/issues/detail?id=6988 >> >> Issue 6894: Add Error tolerant parsing to RB >> http://code.google.com/p/pharo/issues/detail?id=6894 >> >> >> >> Diff information: >> http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1252.diff >> http://ss3.gemstone.com/ss/Pharo20/Compiler-MarcusDenker.360.diff >> http://ss3.gemstone.com/ss/Pharo20/AST-Core-MarcusDenker.103.diff >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > > -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2012

Re: [Pharo-project] Case study/ aside test for tanker

by Martin Dias

how can I try? Gofer it squeaksource: 'MethodWrappers'; package: 'MethodWrappers4'; load. ? On Fri, Nov 16, 2012 at 6:55 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > with the default system, trying to reload methodWrapper in a image with > methodWrapper leads to an error: > MethodStubWrpper cannot be recompiled. > > So I hope that the new classBuilder will be able to do it. > > Stef >

Nov. 16, 2012

Re: [Pharo-project] [update 2.0] #20403

by StÃ©phane Ducasse

I really like the idea of the errorNode. Stef On Nov 16, 2012, at 8:08 PM, Marcus Denker wrote: > 20403 > ----- > > Issue 6989: Move DebuggerMethodMap to Compiler package > http://code.google.com/p/pharo/issues/detail?id=6989 > > Issue 6988: Run #cleanUpForRelease in postscript > http://code.google.com/p/pharo/issues/detail?id=6988 > > Issue 6894: Add Error tolerant parsing to RB > http://code.google.com/p/pharo/issues/detail?id=6894 > > > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1252.diff > http://ss3.gemstone.com/ss/Pharo20/Compiler-MarcusDenker.360.diff > http://ss3.gemstone.com/ss/Pharo20/AST-Core-MarcusDenker.103.diff > > -- > Marcus Denker -- http://marcusdenker.de > >

Nov. 16, 2012