- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [^ 1] and ifCurtailed:

by Frank Shearar

On 16 November 2012 16:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I'm updating the exception chapter to show the interplay between exception and ensure/ifcurtailed: > > [[ ^ 1 ] > ifCurtailed: [ Transcript show: 'show only curtailed'; cr. ]] > on: Error do: [ :e | > Transcript show: 'error'; cr. "do not show it" > e return: 4 ]. > > normally shows that only the ifCurtailed: argument is executed. > > Now I do not get why when I select > [^ 1] value and execute it I do not get an error telling me that there is no context to return to. > > May be because the evaluation itself creates a context. That's certainly true if you run it from a Workspace. frank > Stef > >

Nov. 17, 2012

Re: [Pharo-project] Please review DrGeo

by Hilaire Fernandes

Le 17/11/2012 09:23, Hilaire Fernandes a Ã©crit : > Ok, I can upload the free version along the complete .app version for > workstations. You can download the APK version from http://drgeo.eu/download-install Direct access the to the 12.10 binary repository: https://gforge.inria.fr/frs/?group_id=1308&release_id=7576 Thanks Hilaire

Nov. 17, 2012

Re: [Pharo-project] Please review DrGeo

by Hilaire Fernandes

Le 16/11/2012 18:59, Phil (list) a Ã©crit : > I agree that it may not be worth the effort since you could also put an apk download link on a website that would let the majority of the users who for whatever reason can't or don't want to use the Play Store use DrGeo (assuming you're not concerned about collecting revenue). I'll let others speak to the pros and cons of alternate markets and mainly wanted to pass along that you're not limited should one or more of them make sense for you or your users. Ok, I can upload the free version along the complete .app version for workstations. Hilaire

Nov. 17, 2012

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

by StÃ©phane Ducasse

Thanks this is good to know that Christian library is able to parse PDF. This is a really nice addition to our biotope. On Nov 17, 2012, at 3:34 AM, askoh wrote: > 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] about sharing class binding and others

by StÃ©phane Ducasse

> 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. Yes I would like to measure that too. My benchmarks were to measure the worse case where we have to manually update the methods each time the class is modified.

Nov. 17, 2012

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

by StÃ©phane Ducasse

On Nov 16, 2012, at 11:44 PM, Marcus Denker 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. Excellent we could try to work on autocompletion of code :) by trying to smartly substituting the errorCodeNode by the smallest closing element :) Stef

Nov. 17, 2012

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

by StÃ©phane Ducasse

then load again but this other package. In fact the names of the package and categories are totally insane :) On Nov 16, 2012, at 11:37 PM, Martin Dias wrote: > 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. 17, 2012

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