- Pharo-dev - lists.pharo.org

Missing mcz versions?

by Stephan Eggermont

Projects that load packages using Metacello, tend not to look in Pharo50 and Pharo50Inbox for new versions of those packages. I noticed the Rubric version in Moose 6 to be significantly behind the one in Pharo 5... Can we automatically copy back the inbox/integrator version to its repo? Stephan

Oct. 10, 2015

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

by Nicolai Hess

2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Hello Eliot, and thanks for your time. >> >> >> In our (pharo) implementation for sourceNodeForPC, we start at the >> AST-Node of >> the compiled method, get the IR (IntermediateRepresentation) and scan >> this sequence of IRNodes >> until we finally find that one, that maps to the bytecode of the closure >> creation code (this should be a IRPushClosureCopy). >> The problem is now, we don't find (always) the right IRNode, and it >> depens on the number of local temps, if this is > 3 we don't hit the right >> one. >> > > That's very strange. Can you construct a synthetic example of two simple > blocks, one with three temps and and one with four temps and show me the > difference in the byte code? > [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a RBBlockNode - ok" Bytecode 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <10> pushTemp: 0 21 <81 43> storeIntoTemp: 3 23 <81 42> storeIntoTemp: 2 25 <81 41> storeIntoTemp: 1 27 <7D> blockReturn 28 <7C> returnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a RBMethodNode - not ok" Bytecode 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <73> pushConstant: nil 21 <10> pushTemp: 0 22 <81 44> storeIntoTemp: 4 24 <81 43> storeIntoTemp: 3 26 <81 42> storeIntoTemp: 2 28 <81 41> storeIntoTemp: 1 30 <7D> blockReturn 31 <7C> returnTop As I wrote above, in Pharo, to get the sourceNode we try to find the push closure bytecode from "startpc - 1" by traversing the IR and try to get the IRNode with matching "bytecodeOffset". The bytecodeOffsets for the above blocks: [ :x | | a b c | a:=b:=c:=x ] "bytecodeOffset -> IR" 19->pushClosureCopyCopiedValues: #() args: #(#x) 28->returnTop 20->pushTemp: #x 22->storeTemp: #c 24->storeTemp: #b 26->storeTemp: #a 27->blockReturnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "bytecodeOffset -> IR" 20->pushClosureCopyCopiedValues: #() args: #(#x) 31->returnTop 21->pushTemp: #x 23->storeTemp: #d 25->storeTemp: #c 27->storeTemp: #b 29->storeTemp: #a 30->blockReturnTop Both blocks don't have a bytecodeOffset matching the bytecode of the pushclosure (13), but we start the search from "startpc - 1" (= 16) and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or 4) For the first block, this works bytecodeOffset 19 = 16 - (-3) For the second block this does not work, somehow the bytecodeoffset value depends on the number of local temps. And for the second block this is one greater. > And my interpretation was, the IRPushClosureCopy node has the wrong >> "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) >> depends on the number of local temps, but maybe this is right (for >> whatever this is used) and we are just using it wrong for in this situation. >> > > So you need to ask Marcus how to interpret bytecodeOffset. The thing is, > it should be simple. One has: > > BlockCreationBytecode > any number of pushConstant: nil's (0 to N) > first byte code in block > last bytecode in block (always a blockReturnTop) > > and a block's startup is always that of the byte immediately following the > BlockCreationBytecode. So if the byte code offset is somehow the span of > the "any number of pushConstant: nil's (0 to N)" then there's a bug in the > IR somewhere when the number of temps is > 3. But if that's not what it > means then, well, I don't know what the problem is. > >

Oct. 10, 2015

Re: [Pharo-dev] 50378 -> builds need to be redone?

by Stephan Eggermont

On 10-10-15 20:41, stepharo wrote: > Hi stefan > > could you open a bug entry and publish a merge? > We participated to an hackaton with esteban, pablo, kevin and cyril and we > are not really happy about the tools, the frameworks... > :( I can fix those. How do I check for (partially?) missing source code? Stephan

Oct. 10, 2015

Re: [Pharo-dev] 50378 -> builds need to be redone?

by stepharo

Hi stefan could you open a bug entry and publish a merge? We participated to an hackaton with esteban, pablo, kevin and cyril and we are not really happy about the tools, the frameworks... :( Le 10/10/15 10:38, Stephan Eggermont a Ã©crit : > On 10-10-15 10:28, Stephan Eggermont wrote: >> >> RubFloatingEditorBuilder>>whenReturnEntered: anAnnouncement >> >> RubFloatingEditorBuilder class>>exampleCommandLauncher >> >> RubFloatingEditorBuilder class>>exampleEditableStringMorph >> > > In Inbox theer are two 285s, and changes from Alain were not merged > > Stephan > > >

Oct. 10, 2015

Re: [Pharo-dev] [Moose-dev] Re: Roassal3D is moving...

by Yuriy Tymchuk

I do not remember the causes under first question. Something was broken and some layouts were not working. Iâve made a heavy usage of classes that align all elements alone some pane, and they were removed from RoassalWoden, so I have to add them as my own classes. Also Iâve added a lot of helper methods to the bounding box class, like getting its corrections. Secondly itâs not really an issue of Woden but more of the way Iâve designed ViDI. There is actually no such thing as a âcity layoutâ. If you take a look at the latest CodeCity by Ricky, there are plenty layouts (like rectangle packing, grid, wall, stack) and a nice way to compost them. Now besides having this functionality I also wanted to be able to dynamically change the view i.e. method getâs deleted, visualization is re-layedout. Thatâs why I have a custom âBuildingâ classes, that know their bricks (methods) and can lay them out and inform the parent container if the bonds were changed. The point is that ViDI should not be restricted only to 3D so I donât want to code all the re-layout logic into 3D subclasses. I think that at the moment I can just port orbiting controls to the old Roassal3D. Maybe in the future I will have time to create ViDI v2. Or maybe Iâll find a student willing to do that :) Uko > On 10 Oct 2015, at 13:18, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Yes, I would like to understand why you cannot migrate to woden > Alexandre > > Le 10 oct. 2015 Ã 04:55, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> a Ã©crit : > >> >> >> Le 9/10/15 19:59, Yuriy Tymchuk a Ã©crit : >>> 2 reasons: >>> >>> 1) something is always incompatible (Iâve tried 2 times already) >>> 2) I have too many things hardcoded in Roassal3D subclasses. I have to move it into a proper model, and this will take time. >> >> >> Alex you should have a look at the missing hooks mentioned by Yuriy because I'm quite sure that other >> people will have the same problems and this is not good to duplicate effort. >> >> Yiriy can you point alex to the hardcoded points? >> >>> >>> Iâll take a look at the Orbiter. Although as far as I remember Roassal3D and Woden have different interfaces. >>> >>> Cheers. >>> Uko >>> >>> >>>> On 09 Oct 2015, at 19:54, Alexandre Bergel < <mailto:alexandre.bergel@me.com>alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >>>> >>>> Ah sorry. >>>> Teseo has written the class OrbitController. I think you should be able to reuse it for Roassal3d Old. But why not trying to migrate to Woden instead? >>>> >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>>> On Oct 9, 2015, at 2:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>>> >>>>> No, the control the interaction that moves you around the object when you drag mouse instead of "rotating your headâ as in fps game. >>>>> >>>>> Uko >>>>> >>>>> >>>>>> On 09 Oct 2015, at 19:11, Alexandre Bergel < <mailto:alexandre.bergel@me.com>alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >>>>>> >>>>>> By flyover you mean having a text tooltip? >>>>>> >>>>>> Alexandre >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel <http://www.bergel.eu/>http://www.bergel.eu <http://www.bergel.eu/> >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>>> On Oct 9, 2015, at 12:40 PM, Yuriy Tymchuk < <mailto:yuriy.tymchuk@me.com>yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>>>>> >>>>>>> No, honestly Iâd really appreciate if someone can help me to add this flyover interaction to ViDI, so we can run some kind of controlled experiment on it (and for now itâs not an option to move ViDI to Woden). >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >>> >>

Oct. 10, 2015

Re: [Pharo-dev] [Moose-dev] Re: Roassal3D is moving...

by Alexandre Bergel

Yes, I would like to understand why you cannot migrate to woden Alexandre > Le 10 oct. 2015 Ã 04:55, stepharo <stepharo(a)free.fr> a Ã©crit : > > > > Le 9/10/15 19:59, Yuriy Tymchuk a Ã©crit : >> 2 reasons: >> >> 1) something is always incompatible (Iâve tried 2 times already) >> 2) I have too many things hardcoded in Roassal3D subclasses. I have to move it into a proper model, and this will take time. > > > Alex you should have a look at the missing hooks mentioned by Yuriy because I'm quite sure that other > people will have the same problems and this is not good to duplicate effort. > > Yiriy can you point alex to the hardcoded points? > >> >> Iâll take a look at the Orbiter. Although as far as I remember Roassal3D and Woden have different interfaces. >> >> Cheers. >> Uko >> >> >>> On 09 Oct 2015, at 19:54, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> Ah sorry. >>> Teseo has written the class OrbitController. I think you should be able to reuse it for Roassal3d Old. But why not trying to migrate to Woden instead? >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>>> On Oct 9, 2015, at 2:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>> >>>> No, the control the interaction that moves you around the object when you drag mouse instead of "rotating your headâ as in fps game. >>>> >>>> Uko >>>> >>>> >>>>> On 09 Oct 2015, at 19:11, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>> >>>>> By flyover you mean having a text tooltip? >>>>> >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>>> On Oct 9, 2015, at 12:40 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>>> >>>>>> No, honestly Iâd really appreciate if someone can help me to add this flyover interaction to ViDI, so we can run some kind of controlled experiment on it (and for now itâs not an option to move ViDI to Woden). >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

Oct. 10, 2015

Re: [Pharo-dev] 50378 -> builds need to be redone?

by Stephan Eggermont

On 10-10-15 10:28, Stephan Eggermont wrote: > > RubFloatingEditorBuilder>>whenReturnEntered: anAnnouncement > > RubFloatingEditorBuilder class>>exampleCommandLauncher > > RubFloatingEditorBuilder class>>exampleEditableStringMorph > In Inbox theer are two 285s, and changes from Alain were not merged Stephan

Oct. 10, 2015

50378 -> builds need to be redone?

by Stephan Eggermont

RubFloatingEditorBuilder>>whenReturnEntered: anAnnouncement RubFloatingEditorBuilder class>>exampleCommandLauncher RubFloatingEditorBuilder class>>exampleEditableStringMorph

Oct. 10, 2015

Re: [Pharo-dev] [Moose-dev] Re: Roassal3D is moving...

by stepharo

Le 9/10/15 19:59, Yuriy Tymchuk a Ã©crit : > 2 reasons: > > 1) something is always incompatible (Iâve tried 2 times already) > 2) I have too many things hardcoded in Roassal3D subclasses. I have to > move it into a proper model, and this will take time. Alex you should have a look at the missing hooks mentioned by Yuriy because I'm quite sure that other people will have the same problems and this is not good to duplicate effort. Yiriy can you point alex to the hardcoded points? > > Iâll take a look at the Orbiter. Although as far as I remember > Roassal3D and Woden have different interfaces. > > Cheers. > Uko > > >> On 09 Oct 2015, at 19:54, Alexandre Bergel <alexandre.bergel(a)me.com >> <mailto:alexandre.bergel@me.com>> wrote: >> >> Ah sorry. >> Teseo has written the class OrbitController. I think you should be >> able to reuse it for Roassal3d Old. But why not trying to migrate to >> Woden instead? >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Oct 9, 2015, at 2:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >>> <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> No, the control the interaction that moves you around the object >>> when you drag mouse instead of "rotating your headâ as in fps game. >>> >>> Uko >>> >>> >>>> On 09 Oct 2015, at 19:11, Alexandre Bergel <alexandre.bergel(a)me.com >>>> <mailto:alexandre.bergel@me.com>> wrote: >>>> >>>> By flyover you mean having a text tooltip? >>>> >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>>> On Oct 9, 2015, at 12:40 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >>>>> <mailto:yuriy.tymchuk@me.com>> wrote: >>>>> >>>>> No, honestly Iâd really appreciate if someone can help me to add >>>>> this flyover interaction to ViDI, so we can run some kind of >>>>> controlled experiment on it (and for now itâs not an option to >>>>> move ViDI to Woden). >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

Oct. 10, 2015

Re: [Pharo-dev] Smalltalkhub instable

by stepharo

do we have a document to show how to do such reboot? Le 7/10/15 16:55, Marcus Denker a Ã©crit : > >> On 07 Oct 2015, at 15:47, Blondeau Vincent >> <vincent.blondeau(a)worldline.com >> <mailto:vincent.blondeau@worldline.com>> wrote: >> >> Hi, >> It is very hard to work because Smalltalkhub is very instable today. >> I wanted to launchhttps://ci.inria.fr/moose/job/moose-6.0but I get >> either an 400 or 500 errorâ¦ (It seems to work now but for how long?) >> Can somebody could look at this issue ? > I restarted apacheâ¦which seems to be the source of the problem when > loading static files makes problems. > > Marcus >

Oct. 10, 2015