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

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

Re: [Pharo-dev] WhatsUp from: 2013-07-01 until: 2013-07-14

by Damien Cassou

On Mon, Jul 1, 2013 at 7:00 AM, <seaside(a)rmod.lille.inria.fr> wrote: > ### Here's what I've been up to since the last WhatsUp: > prepare and give Pharo tutorial at ECOOP, Montpellier, France prepare a Pharo cheat sheet flyer with Damien Pollet and Vincent Blondeau Pharo launcher: improve code, add tests, and some features Review many bugs and fixes some Rewrite all user-directory logic (home, desktop, documents, preferences) to use environment variables (linux, macosx, windows) Worked with Sebastian on trait-related code (bug fixing mostly) update pharo vm for ubuntu > ### What's next, until 2013-07-14 (*): > release the first version of Pharo Launcher -- 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

Re: [Pharo-dev] Visual element - Pogress bar.

by Mariano Vicente

Yes is just exactly I was searching for. thanks Ben. âRegards, Mariano On Fri, Jul 5, 2013 at 7:13 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Just that you know, by opening the example, the slider is far too big. > > If you set its size properly, it will look like your screenshot (more or > less ^^) > > Ben > > On Jul 5, 2013, at 12:03 PM, Mariano Vicente <m.vicent(a)gmail.com> wrote: > > In the screenshot don't look like as a progress bar. > â â > How can use it? I write in the workspace and is unknow. > Should download some package? > â â > (I'm using pharo 3.0) > > âRegards, > Mariano > > > On Fri, Jul 5, 2013 at 6:51 AM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> Is a SlideMorph what you are looking for ? >> >> <Screen Shot 2013-07-05 at 11.51.04 AM.png> >> Ben >> >> On Jul 5, 2013, at 11:36 AM, Mariano Vicente <m.vicent(a)gmail.com> wrote: >> >> Hello >> I'm searching for a visual component such as >> â video â >> progress bar >> â / seek bar or something like this: >> [image: Inline image 1] >> >> are there something like it ? >> >> âRegards, >> Mariano >> >> >> > >

July 5, 2013

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

by Alexandre Bergel

Yes, the RMoD crew did an amazing job! Alexandre Le 05-07-2013 Ã 7:01, kilon <thekilon(a)yahoo.co.uk> a Ã©crit : > Looks like NBOpenGL opened the door to many graphics projects , including > mine, these are truly fascinating times for pharo and would love to take a > look at Roassal 3d when it is released. Keep up the great work ;) > > > > -- > View this message in context: http://forum.world.st/Pharo-dev-Roassal-3d-is-on-its-way-tp4697319p4697525.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 5, 2013

Re: [Pharo-dev] NativeBoost and lacking string argument/return handling

by Henrik Sperre Johansen

Was leaving work in a hurry there, think I forgot a not and some smileys in the last post ;) Anyways, in combination with an encoding opt, a nice addition (for those functions expecting size of string as separate parameter) would be being able to specify strLength(myString) as the size parameter, and have it computed after conversion, otherwise you still have to do it all in an image-side wrapper to get the correct number... 2 weeks vacation upcoming, I guess I got plans if the weather is bad ;) Cheers, Henry

July 5, 2013