- Pharo-dev - lists.pharo.org

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

by Alexandre Bergel

Yes, we are aware of it. We are very fortunate that Ronie is expert in OpenGl and low level stuff. Improving NBOpenGL will definitely be part of our effort. Alexandre Le 06-07-2013 Ã 4:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > cool! > > Now pay attention that if you do not invest in the NBOpenGL layer to understand it and make it better > you will get frustrated and igor cannot spend time on it. > > Stef > > 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >

July 6, 2013

FileReference(Object)>>doesNotUnderstand: #other

by Andrei Vasile Chis

Hi, This code fails in both Pharo 2 and Pharo 3: 'FileSystem disk root children sorted' It throws this exception: FileReference(Object)>>doesNotUnderstand: #other Andrei

July 6, 2013

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

by GOUBIER Thierry

This is very usefull for production deployment. I'll make a try and provide a slice if I succeed. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Igor Stasenko [siguctua(a)gmail.com] Date d'envoi : vendredi 5 juillet 2013 17:29 Ã : Pharo Development List Objet : Re: [Pharo-dev] NativeBoost with no access to sources Here is another quick and dirty recipe 4U: - make a extension method in CompiledMethod nbEnsureTempNames self propertyValueAt: #tempNames ifAbsent: [ self propertyValueAt: #tempNames put: self tempNames ] nbTempNames ^ self propertyValueAt: #tempNames NativeBoost class>>prepareForProduction CompiledMethod allInstancesDo: [:aMethod | ((aMethod primitive = 117) and: [ | lit | lit := aMethod literalAt: 1. lit first = #NativeBoostPlugin and: [ lit second == #primitiveNativeCall]]) ifTrue: [ aMethod nbEnsureTempNames ]. ] (and then sure thing, make sure to use #nbTempNames instead of tempNames). but for the future, i want a clear protocol in CompiledMethod to do that, and do not make it depend on system changes. Because if i do, the stuff which works in 2.0 (or 3.0) will suddenly stop working in next version, because of changes in system.. that's why i against even thinking that NB having something to do with method's source code. It needs method's argument names, and nothing else, period. -- Best regards, Igor Stasenko.

July 6, 2013

Re: [Pharo-dev] [Issue tracker] Please have a look at your issues!

by GOUBIER Thierry

Thanks Stephane, Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Date d'envoi : samedi 6 juillet 2013 10:56 Ã : Pharo Development List Objet : Re: [Pharo-dev] [Issue tracker] Please have a look at your issues! Thierry I will add you to the pharo team SmalltalkHub will support public inbox soon! Stef On Jul 5, 2013, at 1:19 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 05/07/2013 09:00, Marcus Denker a Ã©crit : >> 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 > > All the 2.0 backports I have been looking at have fixes waiting for review... I'm using the fixes on a daily basis (loading by hand the relevant SLICES). > >> and 3.0: >> >> https://pharo.fogbugz.com/f/filters/37/3-0-Work-Needed > > For those I'm involved in, I don't have access rights to upload SLICES, so I have stored them under http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main. > (loading by hand the slices, otherwise 3.0 does not even work at all for me). > > Thierry > > >> >> 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 >> >> > > -- > 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 6, 2013

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

by GOUBIER Thierry

You don't consider NB to be core ? Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Date d'envoi : samedi 6 juillet 2013 11:04 Ã : Pharo Development List Objet : Re: [Pharo-dev] NativeBoost with no access to sources Now with Opal in and the API rationalisation we will get stable. I agree that we should avoid core code in external packages. Stef > Here is another quick and dirty recipe 4U: > > - make a extension method in CompiledMethod > > nbEnsureTempNames > > self propertyValueAt: #tempNames ifAbsent: [ > self propertyValueAt: #tempNames put: self tempNames > ] > > nbTempNames > ^ self propertyValueAt: #tempNames > > > NativeBoost class>>prepareForProduction > > CompiledMethod allInstancesDo: [:aMethod | > ((aMethod primitive = 117) and: [ | lit | lit := aMethod literalAt: 1. > lit first = #NativeBoostPlugin and: [ lit second == > #primitiveNativeCall]]) ifTrue: [ > aMethod nbEnsureTempNames > ]. > ] > > (and then sure thing, make sure to use #nbTempNames instead of tempNames). > > but for the future, i want a clear protocol in CompiledMethod to do > that, and do not make it depend on system changes. > Because if i do, the stuff which works in 2.0 (or 3.0) will suddenly > stop working in next version, > because of changes in system.. that's why i against even thinking that > NB having something to do with method's source code. It needs method's > argument names, and nothing else, period. > > -- > Best regards, > Igor Stasenko. >

July 6, 2013

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

by StÃ©phane Ducasse

Now with Opal in and the API rationalisation we will get stable. I agree that we should avoid core code in external packages. Stef > Here is another quick and dirty recipe 4U: > > - make a extension method in CompiledMethod > > nbEnsureTempNames > > self propertyValueAt: #tempNames ifAbsent: [ > self propertyValueAt: #tempNames put: self tempNames > ] > > nbTempNames > ^ self propertyValueAt: #tempNames > > > NativeBoost class>>prepareForProduction > > CompiledMethod allInstancesDo: [:aMethod | > ((aMethod primitive = 117) and: [ | lit | lit := aMethod literalAt: 1. > lit first = #NativeBoostPlugin and: [ lit second == > #primitiveNativeCall]]) ifTrue: [ > aMethod nbEnsureTempNames > ]. > ] > > (and then sure thing, make sure to use #nbTempNames instead of tempNames). > > but for the future, i want a clear protocol in CompiledMethod to do > that, and do not make it depend on system changes. > Because if i do, the stuff which works in 2.0 (or 3.0) will suddenly > stop working in next version, > because of changes in system.. that's why i against even thinking that > NB having something to do with method's source code. It needs method's > argument names, and nothing else, period. > > -- > Best regards, > Igor Stasenko. >

July 6, 2013

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

by StÃ©phane Ducasse

cool! Now pay attention that if you do not invest in the NBOpenGL layer to understand it and make it better you will get frustrated and igor cannot spend time on it. Stef 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

July 6, 2013

Re: [Pharo-dev] [Issue tracker] Please have a look at your issues!

by StÃ©phane Ducasse

Thierry I will add you to the pharo team SmalltalkHub will support public inbox soon! Stef On Jul 5, 2013, at 1:19 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 05/07/2013 09:00, Marcus Denker a Ã©crit : >> 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 > > All the 2.0 backports I have been looking at have fixes waiting for review... I'm using the fixes on a daily basis (loading by hand the relevant SLICES). > >> and 3.0: >> >> https://pharo.fogbugz.com/f/filters/37/3-0-Work-Needed > > For those I'm involved in, I don't have access rights to upload SLICES, so I have stored them under http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main. > (loading by hand the slices, otherwise 3.0 does not even work at all for me). > > Thierry > > >> >> 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 >> >> > > -- > 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 6, 2013

Call for a chapter on Magritte

by StÃ©phane Ducasse

Hi guys I would love to have a nice chapter on Magritte, but I need help and I would like to see how other people would sell it. I created https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english/tr… so if people want to help you are welcome Stef

July 6, 2013

Fwd: [Pharo-users] Pharo on Fedora 19

by Damien Cassou

---------- Forwarded message ---------- From: Daniel Miranda <danielkza2(a)gmail.com> Date: Fri, Jul 5, 2013 at 4:32 AM Subject: Re: [Pharo-users] Pharo on Fedora 19 To: pharo-users(a)lists.pharo.org Libraries reinstaller, problem persists, Pharo is definitely stuck on findMethodWithPrimitiveFromContextUpToContext(). It looks like a problem during initialization, way before graphics drivers would get in the way. As I mentioned the 3.0 alpha runs OK, which further raises my suspicions of a VM bug (what would be special about my system to cause is a more complex matter). Daniel On Thu, Jul 4, 2013 at 11:22 PM, danielkza <danielkza2(a)gmail.com> wrote: > I'll try reinstalling the libraries as instructed. I'm currently using the > latest proprietary NVIDIA drivers, they may the problem. I suspect not > because I tried the 3.0 alpha and it ran fine. > > > > -- > View this message in context: > http://forum.world.st/Pharo-on-Fedora-19-tp4697358p4697455.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 5, 2013