- Pharo-dev - lists.pharo.org

[update 3.0] #30256

by Marcus Denker

July 5, 2013

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

by Goubier Thierry

Le 04/07/2013 19:11, Igor Stasenko a Ã©crit : > On 4 July 2013 13:07, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >> >> >> 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. Could you rather test for unability to get the source of the method and raise a NB-defined error? So that I could write a fallback on non-NB code with a on: do:. Please :) (it would then both handle startup related errors and unreadable sources as well). And with a backport to 2.0, because the odds of seeing an Opal based solution on 2.0 are fairly low. >> 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. Well, in almost all cases, arguments were used in the order they were given, which should have been almost foolproof ;) > 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. Is there a real, practical difference between "at compilation time" and "when receiving MethodAdded event"? i.e. is the complexity added in the compilation process worthwhile? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 5, 2013

We need you for a software integration survey (reminder)

by Martin Dias

Hi all, Some time ago we sent an email to ask you contributing to a research to improve tools for software integration. If you maintain a project with multiple contributors, we will greatly appreciate your participation. Your answers will be used for research purposes and to support the development of new tools. You can later access the results of this study, make free use of our tools to support the integration of changes, and maybe receive a gift. We found out that the survey was not properly working on Safari (and may be also some other browsers). And we have now corrected this issue. Up to now, we received 36 full answers and 166 incomplete answers. So we decided to give you an extra month, if you started to fill the survey, please consider resuming filling the survey. For this you only need to go back to the same site: https://sondages.inria.fr/index.php/667625/lang-en If you did not yet fill in the survey, please consider doing it now. Best regards, Martin Dias, Nicolas Anquetil, Veronica Isabel Uquillas, StÃ©phane Ducasse and the RMOD Inria team

July 5, 2013

[Issue tracker] Please have a look at your issues!

by Marcus Denker

Hi, We should do a pass over all issues. e.g. -> is your bug still relevant? -> if you submitted a fix, maybe the bug status is wrong and therefore nobody looked at it? -> if you added a verbal description of how to fix something, consider submitting code in addition (people have just no idea how much easier it is to deal with machine readable code than half-a-page of proseâ¦) -> You where involved in a discussion about a bug. So now go trough it and summarize: What is the next *action* that needs to be done to close the issue? You can get a list of *all* open issues: https://pharo.fogbugz.com/f/filters/33/All-Opened or just the ones for 2.0: https://pharo.fogbugz.com/f/filters/8/2-0-Work-Needed and 3.0: https://pharo.fogbugz.com/f/filters/37/3-0-Work-Needed For the 2.0/3.0 issues, we should decide: are they really of a kind that they need to fixed before we can release? (in 2.0: do we really need to back port? or is it enough to fix in 3.0?) Marcus

July 5, 2013

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