- Pharo-dev - lists.pharo.org

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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

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

July 4, 2013

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 4, 2013

Re: [Pharo-dev] New Consortium Member: Debris Publishing

by Mariano Martinez Peck

Cool! I am working for them and it is a very nice company! Thanks for supporting Pharo. On Thu, Jul 4, 2013 at 12:41 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > New Consortium Member: Debris Publishing > > The Pharo Consortium welcomes a new member company: > > Debris Publishing Inc. : http://debrispublishing.com > > Debris is joining as a Silver Member. > > More about... > - Debris Publishing Inc.: http://debrispublishing.com > - Pharo: http://pharo.org > - Pharo Consortium: http://consortium.pharo.org > > -- Mariano http://marianopeck.wordpress.com

July 4, 2013

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

by Alexandre Bergel

I would be happy to. But I forgot my login and password for http://association.pharo.org Who should I ask for this? Alexandre On Jul 4, 2013, at 11:36 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > alex you should publish that on the pharo association web site. > > > On Jul 4, 2013, at 3:24 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: >> https://www.facebook.com/photo.php?fbid=478025185617417&set=a.3411893793009… >> https://www.facebook.com/photo.php?fbid=478024745617461&set=a.3411893793009… >> >> Cheers, >> Milton & Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 4, 2013

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

by Stephan Eggermont

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

July 4, 2013

Re: [Pharo-dev] Sunburst visualization

by Stephan Eggermont

Sunburst + Roassal3D => Burning Man style CodeCity? Looking good Peace! Stephan

July 4, 2013