October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Problems with a large block

by Eliot Miranda

Hi Nicolai, On Wed, Oct 7, 2015 at 2:13 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-10-07 16:49 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> > On 07 Oct 2015, at 15:49, Marco Naddeo <naddeo(a)di.unito.it> wrote: >> > >> > Hi, >> > >> > I have some problems with the large block at bottom: >> > >> > -sending the message argumentNames gives me an empty array #() >> > -sending the message sourceNode gives me a strange result and not a >> RBBlockNode, as I would expect >> > >> >> This happens already with: >> >> [ :h :s :v | | min chroma hdash X red green blue | ] sourceNode >> >> I will checkâ¦ it is a bug in the mapping pc -> AST. >> > > That's interesting, the way the pc is mapped to the AST (ir > instructionForPC: ) > takes the "length" of the instruction bytecode into account and the length > of a pushclosure includes > all bytes needed for the pushing the local temps (pushConstant nil. > pushConstant nil ....) > > But the startPC of a block context starts at the first push, not after, > that means > > self method sourceNodeForPC: self startpc - 1 > starts the search after the push closure bytecode but before any push > local temp byte code. > > Either we don't include the bytecodes for the "pushConstant:nil" in the > bytecode offset, or we start the search at > > self method sourceNodeForPC: self startpc - 1 + self numLocalTemps > No, no, no, no, no :-). The PC in question is the pc of the block creation byte code. The startpc of a block is the first bytecode following the block creation byte code. That *includes* any pushConstant: nil byte codes establishing temps in the block. Instead, it is expected that "self method sourceNodeForPC: self startpc - 1" answers the same as "self method sourceNodeForPC: self blockCreationPC", where self blockCreationPC is the pc of the block's block creation bytecode. In Squeak we have BlockClosure>>blockCreationPC "Answer the pc for the bytecode that created the receuver." | method | method := self method. ^method encoderClass pcOfBlockCreationBytecodeForBlockStartingAt: startpc in: method This is because we support (as you will soon enough) different byte code sets so it is wrong to assume the size of the block creation bytecode is 4. But for now you could use self method sourceNodeForPC: self startpc - 4 and make sure that the compiler maps a block creation bytecode to the source node for the entire block. The way to think about "self method sourceNodeForPC: self startpc - 1 + self numLocalTemps" not masking sense is that a pc inside the block must map to a statement inside the block, not the block itself. HTH > > >> >> Marcus >> >> >> >> >> >> > -- _,,,^..^,,,_ best, Eliot

Oct. 7, 2015

Re: [Pharo-dev] Issue Tracker Choice

by Alexandre Bergel

It would be interesting indeed. However, I value much more an integration with git. Alexandre > Le 7 oct. 2015 Ã 03:27, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > >> On Oct 6, 2015, at 8:30 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Damien Cassou-2 wrote >>> could you please tell us what you don't like about FogBugz >> >> The main thing is that it's not designed for open source projects. Requiring >> account creation before one can even search the open issues is a huge >> barrier. I would guess most new people will hit that wall and give up on >> sending us valuable bug reports. > > > +1. > > BTW, at ParcPlace we implemented our own. It's not difficult and having something one can tailor is great. Pharo has the relevant web, database & server technology. It would be a great test of the system to implement its own issue tracker. > > > _,,,^..^,,,_ (phone) > >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Issue-Tracker-Choice-tp4854002p4854106.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 7, 2015

Re: [Pharo-dev] [OT] Slides the web way

by phil＠highoctane.be

And maybe some Grafoscopio On Wed, Oct 7, 2015 at 10:09 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > As we have: > > - Pillar to write content in wiki syntax and generate HTML out of it > - Mustache as template engine > - Teapot to easily server static and dynamic web content > > one might create his next Pharo presentations in HTML5 easily: > > http://impress.github.io/impress.js > https://code.google.com/p/io-2012-slides > http://lab.hakim.se/reveal-js/#/ > > and serve it from Pharo > > > > >

Oct. 7, 2015

Re: [Pharo-dev] Problems with a large block

by Nicolai Hess

2015-10-07 16:49 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 07 Oct 2015, at 15:49, Marco Naddeo <naddeo(a)di.unito.it> wrote: > > > > Hi, > > > > I have some problems with the large block at bottom: > > > > -sending the message argumentNames gives me an empty array #() > > -sending the message sourceNode gives me a strange result and not a > RBBlockNode, as I would expect > > > > This happens already with: > > [ :h :s :v | | min chroma hdash X red green blue | ] sourceNode > > I will checkâ¦ it is a bug in the mapping pc -> AST. > That's interesting, the way the pc is mapped to the AST (ir instructionForPC: ) takes the "length" of the instruction bytecode into account and the length of a pushclosure includes all bytes needed for the pushing the local temps (pushConstant nil. pushConstant nil ....) But the startPC of a block context starts at the first push, not after, that means self method sourceNodeForPC: self startpc - 1 starts the search after the push closure bytecode but before any push local temp byte code. Either we don't include the bytecodes for the "pushConstant:nil" in the bytecode offset, or we start the search at self method sourceNodeForPC: self startpc - 1 + self numLocalTemps > > Marcus > > > > > >

Oct. 7, 2015

Re: [Pharo-dev] [OT] Slides the web way

by Ferlicot D. Cyril

Le 07/10/2015 22:09, Torsten Bergmann a Ã©crit : > As we have: > > - Pillar to write content in wiki syntax and generate HTML out of it > - Mustache as template engine > - Teapot to easily server static and dynamic web content > > one might create his next Pharo presentations in HTML5 easily: > > http://impress.github.io/impress.js > https://code.google.com/p/io-2012-slides > http://lab.hakim.se/reveal-js/#/ > > and serve it from Pharo > > > > Hi, You can generate Deck.js presentations with Pillar :) You can see an example with PharoMooc slides[1][2]. (We just need to create a better css and some little adjustments! ) And you can also generate Beamer with the same Pillar file. [1] https://github.com/SquareBracketAssociates/PharoMooc [2] https://ci.inria.fr/pharo-contribution/view/Books/job/PharoMooc/ws/book-res… -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 7, 2015

Re: [Pharo-dev] [OT] Slides the web way

by Esteban A. Maringolo

I used reveal.js vÃa Slides.com for a demo [1] It's produces really nice presentations. Esteban A. Maringolo [1] http://slides.com/emaringolo/oop-smalltalk-back-to-the-future#/ 2015-10-07 17:09 GMT-03:00 Torsten Bergmann <astares(a)gmx.de>: > As we have: > > - Pillar to write content in wiki syntax and generate HTML out of it > - Mustache as template engine > - Teapot to easily server static and dynamic web content > > one might create his next Pharo presentations in HTML5 easily: > > http://impress.github.io/impress.js > https://code.google.com/p/io-2012-slides > http://lab.hakim.se/reveal-js/#/ > > and serve it from Pharo > > > >

Oct. 7, 2015

[OT] Slides the web way

by Torsten Bergmann

As we have: - Pillar to write content in wiki syntax and generate HTML out of it - Mustache as template engine - Teapot to easily server static and dynamic web content one might create his next Pharo presentations in HTML5 easily: http://impress.github.io/impress.js https://code.google.com/p/io-2012-slides http://lab.hakim.se/reveal-js/#/ and serve it from Pharo

Oct. 7, 2015

Re: [Pharo-dev] [ANN] Pharo Catalog web page updated

by Thierry Goubier

Le 07/10/2015 19:17, Esteban Lorenzano a Ã©crit : > Hi, > > I spend some time today adding some functionality top the Pharo > Catalog web page. Is still far from *good* but I think now is a lot > better: > > http://catalog.pharo.org Certainly better :) Thierry > Enjoy, Esteban > > ps: as a âhistoryâ note, Pharo Catalog page was never intended to > last too much, it was going to be replaced for a complete web-page, > and it still will be, but since is not ready and I donât know when it > will be, I think is better to enhance the current one :) > > >

Oct. 7, 2015

Re: [Pharo-dev] [ANN] Pharo Catalog web page updated

by zio su gmail

Thanks Esteban, it's nice :-) Pietro > Hi, > > I spend some time today adding some functionality top the Pharo Catalog web page. > Is still far from *good* but I think now is a lot better: > > http://catalog.pharo.org > > Enjoy, > Esteban > > ps: as a âhistoryâ note, Pharo Catalog page was never intended to last too much, it was going to be replaced for a complete web-page, and it still will be, but since is not ready and I donât know when it will be, I think is better to enhance the current one :) > > > . >

Oct. 7, 2015

Re: [Pharo-dev] [ANN] Pharo Catalog web page updated

by Esteban Lorenzano

btwâ¦ this remembers me that there are A LOT of packages without correct catalog information. I beg project owners to update your configurationsâ¦ a non-findable project is as good as non existent :( Esteban > On 07 Oct 2015, at 19:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I spend some time today adding some functionality top the Pharo Catalog web page. > Is still far from *good* but I think now is a lot better: > > http://catalog.pharo.org > > Enjoy, > Esteban > > ps: as a âhistoryâ note, Pharo Catalog page was never intended to last too much, it was going to be replaced for a complete web-page, and it still will be, but since is not ready and I donât know when it will be, I think is better to enhance the current one :) >

Oct. 7, 2015