July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] SourceCity works

by Tudor Girba

+1 Doru On Jul 4, 2013, at 6:23 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Erwan and all, > > Just to make a few things clear about Roassal 3d vs SourceCity. > > We are currently working on Roassal 3d, which intends to be a nice layer at the top of NBOpenGL and NBXLib to easily create 3d scenes with cubes, lights, camera, interactions, zooming, translucent coloring, clicking/rotating/translating individual elements and so on. Everything that is good for Roassal is equally good for 3D Scene. > > Having a city-like visualization will be one of our first objectives since (i) it is a compelling use of 3D and (ii) it is easy to implement (at least the bases). We started to work on a CityBuilder, to easily create cities from objects and provided metrics. Ideally, it would be great to have SourceCity based on our effort. Not now since we have just started Roassal 3D, but on some point we should merge (this is similar in the 2d World with Mondrian and EyeSee moving from plain Morphic to Roassal). > > Our objective is to offer a great 3d framework to make a truly flying SourceCity. > Does this make sense to you? > > Cheers, > Alexandre > > > > On Jul 4, 2013, at 10:47 AM, Erwan Douaille <douailleerwan(a)gmail.com> wrote: > >> https://ci.inria.fr/pharo-contribution/job/SourceCity/ >> >> done >> >> >> 2013/7/4 Camillo Bruni <camillobruni(a)gmail.com> >> >> On 2013-07-04, at 15:35, Erwan Douaille <douailleerwan(a)gmail.com> wrote: >> >>> I updated the ConfigurationOfSourceCity. >>> >>> Gofer new >>> smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; >>> configuration; >>> load. >>> ConfigurationOfSourceCity loadBleedingEdge >> >> would it make sense to make a jenkins job for this? >> >> >> >> >> -- >> Best regards, >> >> Douaille Erwan <douaille.erwan(a)gmail.com> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- www.tudorgirba.com "Live like you mean it."

July 5, 2013

Re: [Pharo-dev] Sunburst visualization

by Tudor Girba

This looks like really a fantastic job. I cannot wait to see the code :) Doru On Jul 4, 2013, at 3:20 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > We are currently working on a Sunburst based on top of Roassal. Milton is doing a fantastic job! > Here some early screenshots: > > <image copy 2.png><image copy.png><image.png> > > > Milton & Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -- www.tudorgirba.com "If you can't say why something is relevant, it probably isn't."

July 5, 2013

Re: [Pharo-dev] Roassal 3d is on its way

by Usman Bhatti

Very nice. On Thu, Jul 4, 2013 at 8:50 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > +1 > > On Jul 4, 2013, at 12:00 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > Erwan wrote: > >> My question is, why trying to make something which is already working ? > >> I mean, just changing some SourceCity stuff and it will work for > roassal (i guess). > > > > SourceCity is a fixed layout with buildings & blocks. Roassal allows > > switching & combining layouts. So yes, you should be able to do > > a codecity layout with Roassal 3D > > > > Stephan > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

July 4, 2013

Re: [Pharo-dev] Roassal 3d is on its way

by Alexandre Bergel

+1 On Jul 4, 2013, at 12:00 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Erwan wrote: >> My question is, why trying to make something which is already working ? >> I mean, just changing some SourceCity stuff and it will work for roassal (i guess). > > SourceCity is a fixed layout with buildings & blocks. Roassal allows > switching & combining layouts. So yes, you should be able to do > a codecity layout with Roassal 3D > > Stephan -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 4, 2013

Re: [Pharo-dev] Fwd: Artifacts on Linux using NBOpenGL

by Javier PimÃ¡s

Hi, the NB XLib wrapper covers just the basic functionality. It was made just to prove that it's possible, but not extended much far. If you are using the examples provided, they probably fail when the window is closed because the event loop keeps calling XLib functions, passing the pointer to the window object that has already been destroyed. On Thu, Jul 4, 2013 at 2:17 PM, Erwan Douaille <douailleerwan(a)gmail.com>wrote: > HI ! > > I just updated the SourceCity configurationOf, using the latest version of > NBOpenGL. It's running on Linux but i have many artifacts, i just report > you that bug :) > I also have 3 new empty window opened. And if i close them, image closing > and i have this error message in shell. > > wawan@wawan-MS-16F1:~/Downloads/latest$ pharo Pharo-30252.image > XIO: fatal IO error 4 (Interrupted system call) on X server ":0" > after 48 requests (48 known processed) with 1 events remaining. > > > Thanks > > > > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

July 4, 2013

Re: [Pharo-dev] question about UI

by Gisela Decuzzi

Yes! Damien also told me to transform the post into a chapter. Thanks for starting :D I will take a look and finish it next week 2013/7/4 Stephan Eggermont <stephan(a)stack.nl> > Depending on your actual needs, you might get a much faster start > by using Glamour. It allows building an application at a higher > abstraction level. > > Stephan > >

July 4, 2013

Fwd: Artifacts on Linux using NBOpenGL

by Erwan Douaille

HI ! I just updated the SourceCity configurationOf, using the latest version of NBOpenGL. It's running on Linux but i have many artifacts, i just report you that bug :) I also have 3 new empty window opened. And if i close them, image closing and i have this error message in shell. wawan@wawan-MS-16F1:~/Downloads/latest$ pharo Pharo-30252.image XIO: fatal IO error 4 (Interrupted system call) on X server ":0" after 48 requests (48 known processed) with 1 events remaining. Thanks

July 4, 2013

Re: [Pharo-dev] [Moose-dev] Sunburst visualization

by Igor Stasenko

Cool. Low hanging fruits. We all love them :) -- Best regards, Igor Stasenko.

July 4, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Igor Stasenko

On 4 July 2013 13:07, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 04/07/2013 11:58, Igor Stasenko a Ã©crit : > >> On 3 July 2013 23:04, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>> Hi Stephane, >>> >>> I worked around it... as long as I don't make FileReference>>exists as a >>> NB call, then the Changes file will open correctly and NB calls will work >>> after that (Changes opening doesn't use isReadable or isWriteable, which is >>> interesting in itself ;))... But it makes my solution fragile. >>> >>> However, if you make the Changes file not readable (still owned by you, >>> still writeable), many interesting things happen, starting with a nbGetEnv >>> failure and a total unability to quit Pharo apart from a killall pharo. >>> >>> I tried to: >>> - Get NB to accept positional arguments instead of named ones (by >>> catching names like _1, _2). Easy, since apparently the NB generated code >>> just takes an offset on the pointer stack finally (i.e. names are only used >>> to get the index in the arguments array). Seemed to work. >> >> >> can you share this code? i think it doesn't hurts being able to refer >> to method argument by number , not by name, if author wants to. > > > I wondered if it could be both (name and number), but went for the shortest > path, that is the simplest solution: > > NBFFICallout>>loaderFromMethodArgsNamed: argName > > methodArgs > ifNotNil: [ > | index | > (argName first = $_ and: [ argName allButFirst > isAllDigits ]) > ifTrue: [ ^ NBSTMethodArgument new > stackIndex: methodArgs size - argName asUnsignedInteger ]. > index := methodArgs indexOf: argName ifAbsent: [ nil > ]. > index > ifNotNil: [ > "ok, this is a method argument" > ^ NBSTMethodArgument new stackIndex: > methodArgs size - index ] ]. > ^ nil > This looks fine , and i will add it into NB. > Then I tried to change all calls to use numbers, but it ended in a Segfault > (not in NB itself, but somewhere else as if I had a corrupted heap). The end > result with all changes is there: > > http://ss3.gemstone.com/ss/PharoInbox/SLICE-Issue-11102-FileSystemError-Pat… > > If you see where I missed something, I'd be happy to know. > you probably made a mistake somewhere. ;) because counting the argument index, instead of putting its name is error prone. > >>> - Change all NB calls with numbers above to be able to have NB working >>> before / without the Changes file. >>> Ended with a segfault on startup (globalSymbolLoading for GetEnv >>> again), and I gave up. >>> >>> Igor, would there be a way to write the call with the effective arguments >>> instead of #symbols, so that by looking at the bytecode you would get the >>> position in the arguments stack? Or would it be possible to store by hand >>> the source of the methods (triggered by the <pragma>) inside a source cache >>> inside NB for the time being? Or is there an event for NB correct start >>> (with Changes and all ready) so that we can write NB code with a fallback if >>> NB isn't able to work? >>> >> i wanna change it, so that when you compile method with NB primitive, >> it remembers the arg names. > > > Yes, I suspect it would be the best solution. Trap on <primitive: ? If you > track the MethodAdded / MethodRemoved events, you can note all uses of > <primitive:> and cache the info there ? > not cache, just put it into method's attributes, so i can access them later. And not when method added/removed, but at compilation time. > -- Best regards, Igor Stasenko.

July 4, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

July 4, 2013