February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] DrGeo on ARM Android

by Olivier Auverlot

Hi Hilaire, It's very cool ! I will probably working on a projet for an android tablet in the next weeks. That's could be cool to do it with Pharo. Could you share your experience about this subjet ? It will be nice to have a documentation about the problematic of the adaptation and the deploiment of an application made with Pharo on a Android tablet. What are the problems ? How to package the application to distribute ? What are the limitations ? I think many users will be interested to read you because mobility is become a critical subject. Best regards Olivier ;-) www.auverlot.fr > Dimitry and I are working on the DrGeo port to the Android ARM Operating > System. > DrGeo on Pharo with Stack VM proves to be smooth and neat to use. > http://www.drgeo.eu/screenshot-video > > Thanks >

Feb. 24, 2012

Re: [Pharo-project] 1.4 and forward (was Netstyle experience)

by Schwab,Wilhelm K

Stef, New to migrate (below). It works!!! One "bad" thing is the hard-coded version, but it did indeed work as advertised. Thanks!!!! I clearly need to use the mirror in my gofer calls - that probably explains a lot of trouble I've had (hindsight is a wonderful thing). Sleep calls. Bill loadCitezen "1-10 - load Citezen if not installed. 4-10 - this appears to load Seaside too. 6-10 - will no longer load Seaside. 2-12 - force same." Smalltalk at:#CZAuthor ifPresent:[ :aClass | ^self. ]. Gofer new url:'http://ss3.gemstone.com/ss/citezen/'; package:'ConfigurationOfCitezen'; load. ( (Smalltalk at:#ConfigurationOfCitezen ) project version:'0.8') load: { 'NoWeb'}. " Migrate default loadCitezen. Migrate default loadOSProcess. Migrate default loadSeaside. " ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Thursday, February 23, 2012 3:10 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) Stef, I can't do it this minute, but I WILL try it - what else can a member the community do? :) I'm optimistic. THANKS!!! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Thursday, February 23, 2012 3:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) ok here is what I did I took the latest nautilus green version but it will work with the latest pharo Then I took the configurationOfCitezen from MCHttpRepository location: 'http://ss3.gemstone.com/ss/citezen/' user: '' password: '' and I did (ConfigurationOfCitezen project version: '0.8') load: { 'NoWeb'}. and it works. Can you give a try? Stef > Stef, > > I will gladly try, though I thought I was using the up-to-date config. Is there maybe a stale copy in the citezen folder? *THAT* might have fooled me and caused the glitch. Thanks for the prod. I'll try again soon. > > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Thursday, February 23, 2012 11:54 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) > > On Feb 23, 2012, at 10:00 AM, Schwab,Wilhelm K wrote: > >> Stef, >> >> This: >> >> Gofer new >> squeaksource:'MetacelloRepository'; >> package:'ConfigurationOfCitezen'; >> load. >> ( (Smalltalk at:#ConfigurationOfCitezen ) project version: #stable) load: { 'NoWeb'}. >> >> is loading Seaside. Did I do something wrong? > > does not seem so > this is really strange because I'm hacking in and on top of citizen in this moment and I did get problem. >> >> Further, I've hit dependency warning (e.g. a 45 minute?? build stops dead in its tracks). Complaints so far over Transcript streams and Text Morph something or other. It finally bound up over preferences (missing message - detail later). I tried a separate load of Seaside, but it's complaining about preferences out of the gate. >> >> For the "you're just complaining" crowd, I'm simply reporting what is happening. I would very much like to see Jenkins build a 1.4 and then a 1.4+Seaside. > > Ok I will give a try because we migrated citizen to ss30 but we did not republished the configuration in MetacelloRepository. > can you give a try? > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] >> Sent: Thursday, February 23, 2012 3:21 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) >> >> Norbert, >> >> Thanks for the suggestion, but I really need to get things loaded so I can load an even bigger pile of code that I have written. There is also the question of how to capture all of the legacy data; it's not as easy as one might think, as some things are "in the wild." >> >> I've really used this system, and could simply hang at 1.1.1 for a long time - I'm trying to do better than that. >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Norbert Hartl [norbert(a)hartl.name] >> Sent: Thursday, February 23, 2012 3:07 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Cc: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) >> >> Am 23.02.2012 um 08:27 schrieb "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu>: >> >>> Stef, >>> >>> Reading this is encouraging. I have not forgotten about 1.4, I have simply been heavily distracted. SIXX is a concern, as I built a lot on top of it and (I *think*) need to get it loaded in order to evaluate Fuel vs. it. XML parsers are a big part of life for SIXX. Regardless of any change I might make, SIXX should be in the image to load "legacy" data (from last month<g>). >>> >> Bill, >> >> is your real test to use sixx on 1.4? If you just want to test 1.4 then export your data with fuel from an 1.3 image and back into a 1.4 one. This should be pretty easy. >> >> Norbert >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] >>> Sent: Wednesday, February 22, 2012 3:50 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Netstyle experience (was Do not feed the trolls) >>> >>> On Feb 22, 2012, at 1:58 PM, Norbert Hartl wrote: >>> >>>> >>>> Am 22.02.2012 um 13:28 schrieb GermÃ¡n Arduino: >>>> >>>>> Example: xmlrpc died before to born, worked only in 1.1.1, now I must find time to update it to zinc and 1.3 but with the fear that again will not work in 1.4. >>>> >>>> What are your building blocks except http and xml? If you were working on 1.1.1 then xml parser moved quite a bit and zinc appeared on the scene. The changes to adopt xml parser should be minimal. Zinc provides a facade that mimicks backward compatibility. So you could have an easy start. But to be honest the situation is soooo much better with having zinc that you might save some time in development if you use zinc straight away. >>>> And about 1.4: Yes, it moves a lot but zinc and xml do not. Xml is stable since months and the change rate in zinc is also dropping. So you might expect them to be available until...let's say...3 months from now. :) Ok, just kidding, I think the will stay similar for quite some time. >>> >>> Exactly. >>> Doru got **all** the moose tools in 1.4 and some of them like glamour rely a lot on UI changes. >>> I doubt that xmlrpc got any impacted on Morphic change. We do not change XML (but the XML maintainers did) >>> and Zinc is just much much much better than the old system so it should be not difficult to adapt especially if you ask. >>> >>> Stef >>> >> >> >> > > >

Feb. 24, 2012

Re: [Pharo-project] Increasing bots traffic

by Marcus Denker

On Feb 23, 2012, at 10:46 PM, Nicolas Cellier wrote: > Just curious, what is the goal of Jenkins build reports > - focus developers attention on failing tests The reports will stop as soon as the build is green. But in general, the *only* person who has *ever* added a bug report because a test started to fail was me. Nobody looks at the failing tests! Nobody realises that when a test starts to fail. "It might have been that change last week". Great. I want to know *immediatly* when as change breaks a test. Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 24, 2012

Re: [Pharo-project] 1.4 and forward (was Netstyle experience)

by Schwab,Wilhelm K

great! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Thursday, February 23, 2012 10:36 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) On 23 February 2012 23:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > AHHHHH - 1.4 and seaside - COOL. I'll be getting that image - sorry, so many links, too little gray matter... > Just for the future: everything we care about is on Jenkins server or will be in future. :) > THANKS!!!!!! > > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Yanni Chiu [yanni(a)rogers.com] > Sent: Thursday, February 23, 2012 1:35 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) > > On 23/02/12 4:00 AM, Schwab,Wilhelm K wrote: >> >> For the "you're just complaining" crowd, I'm simply reporting what is >> happening. I would very much like to see Jenkins build a 1.4 and >> then a 1.4+Seaside. > > Doesn't the build server have that at: > https://ci.lille.inria.fr/pharo/job/Seaside%20Pharo%201.4/ > > You might also have a look at the list of "Downstream Projects" listed at: > https://ci.lille.inria.fr/pharo/job/Pharo%201.4/ > > > -- Best regards, Igor Stasenko.

Feb. 24, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Igor Stasenko

On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia(a)gmail.com> wrote: > On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> Nooo!!! he comes from Java!! he starts with index 0. Kill him!!!Â ;) > > Ooops... Time to get a new identity :) > > > On 23 February 2012 19:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Sure we know. >> And we also know that it requires effort and lot of people are talking. > > I know there's a loooong way to see what CodeBubbles can do, and that > requires to do a big effort, but imagined that some kind of > alternative - I'm not sure that CB is **exactly** what I want (sure > Java-ers want to see **something more** than just a file pimped with > colours, but Smalltalk **allready has** much more than a text file - > have real code) Â - could be very less effort-consuming. Making the > current browser (Nautilus? - newbie here :) ) pop a new > Â¿window?Â¿morph? showing a method instead of updating a single pane > (the current one showing method's source) don't seems to be so "far" > away to me. > > Of course that's my point of view, based on what I imagine that could > be. I should spend some time to see how it is implemented, and to see > if it really is that simple, but anyway trust you if you say is a huge > effort... > Well, popping out a new morph every time you clicking around is easy part. The hard part is to make this stuff really consistent and easy to use for navigation and development. It requires far more serious work than just spending 2 hours implementing "bubbling" behavior. > > Cheers :) > -- Best regards, Igor Stasenko.

Feb. 24, 2012

Re: [Pharo-project] 1.4 and forward (was Netstyle experience)

by Igor Stasenko

On 23 February 2012 23:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > AHHHHH - 1.4 and seaside - COOL. Â I'll be getting that image - sorry, so many links, too little gray matter... > Just for the future: everything we care about is on Jenkins server or will be in future. :) > THANKS!!!!!! > > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Yanni Chiu [yanni(a)rogers.com] > Sent: Thursday, February 23, 2012 1:35 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 1.4 and forward (was Netstyle experience) > > On 23/02/12 4:00 AM, Schwab,Wilhelm K wrote: >> >> For the "you're just complaining" crowd, I'm simply reporting what is >> happening. Â I would very much like to see Jenkins build a 1.4 and >> then a 1.4+Seaside. > > Doesn't the build server have that at: > Â https://ci.lille.inria.fr/pharo/job/Seaside%20Pharo%201.4/ > > You might also have a look at the list of "Downstream Projects" listed at: > Â https://ci.lille.inria.fr/pharo/job/Pharo%201.4/ > > > -- Best regards, Igor Stasenko.

Feb. 24, 2012

Re: [Pharo-project] DrGeo on ARM Android

by Igor Stasenko

On 22 February 2012 12:58, Guido Stepken <gstepken(a)googlemail.com> wrote: > Am 22.02.2012 10:33 schrieb "Hilaire Fernandes" > <hilaire.fernandes(a)edu.ge.ch>: > > >> >> Dimitry and I are working on the DrGeo port to the Android ARM Operating >> System. >> DrGeo on Pharo with Stack VM proves to be smooth and neat to use. >> http://www.drgeo.eu/screenshot-video >> >> Thanks >> >> -- >> Dr. Geo > > I read about Dr.Geo in many educational journals, a very good reputation - > worldwide. > > But sorry to tell you (yes, the troll again!), but if you had taken the c++ > codebase, with little work compiled it with XCode, uploaded it to appstore, > you could have sold ... hmmm ... 100.000-400.000 for 1.50â¬ each.... > You know, mr.Troll, some people having more honorable aims than just getting $$$$ for themselves. But don't try to understand it, i know it won't fit into your head. > You loose much, much, much money on going with Pharo! > > Wrong marketing. > > Have fun! > > Guido Stepken -- Best regards, Igor Stasenko.

Feb. 24, 2012

Re: [Pharo-project] fun with NBOpenGL

by Igor Stasenko

On 23 February 2012 23:23, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Great to see 3D on Pharo again! > > Just a remark, somewhere there should be stated that directly loading > vertex one by one with glVertex3f(..); Â is deprecated in the latest > OpenGL. In favor of mechanisms that load the geometry to the renderer > as a whole, as for example vertex buffer objects. > I know it. But as said before in this topic, it is "tip of the iceberg". People who really know how to properly deal with modern OpenGL implementation should know it by themselves. The purpose of NBOpenGL is give them a way to do it in smalltalk. Not less but not more. > In short, in the examples is ok to use, for learning the inner > workings of OpenGL. > Newer examples should make use of current practices of OpenGL. > I think that Nehe examples web page states that. > > I think that a framework such as Lumiere, would be needed to provide > higher abstractions and more efficient handling of geometry. > Maybe when i finish my Phd, i can continue to work on it. > > Fernando > > > On Thu, Feb 23, 2012 at 10:13 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Excellent. >> Could you use large fonts :) >> The idea is that we should be able to see the code and to follow. >> >> Stef >> >> On Feb 23, 2012, at 8:38 PM, Lawson English wrote: >> >>> My videos on Croquet OpenGL discuss the first 6. In fact, that GUI texture thing was done only using the techniques used in NeHe 6. >>> >>> I'll go back and recreate the NeHe code for 2-6 using NBOpenGL as soon as I get your updated code installed. >>> >>> L >>> >>> On 2/23/12 12:13 PM, Igor Stasenko wrote: >>>> We actually should try and translate more NeHe tutorials[1]. I hope, >>>> Stephane didn't found it hard to follow, because it is merely >>>> copy-pasting C code and rewriting the syntax. >>>> >>>> http://nehe.gamedev.net/tutorial/lessons_01__05/22004/ >>>> http://nehe.gamedev.net/tutorial/lessons_06__10/17010/ >>>> http://nehe.gamedev.net/tutorial/lessons_11__15/28001/ >>>> ... >>>> >>> >>> >>> >> >> > -- Best regards, Igor Stasenko.

Feb. 24, 2012

[Pharo-project] fun with NBOpenGL

by Igor Stasenko

On 24 February 2012 01:26, Lawson English <lenglish5(a)cox.net> wrote: > I was experimenting a little bit. What is the best way, using code, Â to put > an GLViewportMorph into a scrollpane? the things I have tried so far seem to > either crash Pharo or not work as I expect. > By default GLViewportMorph copying a rendered stuff from gl buffer directly to Display form to avoid extra copying. This trick is not fully compatible with morphic, since it ignoring clipping bounds etc. If you want to have full integration with morphic, first turn on "useOwnForm" flag first then viewport will copy rendered pixels into own buffer, which is then can be used for subsequent drawing on morphic canvas. See GLViewportMorph>>drawOn: aCanvas Probably we should add a bounds checking in NBGLDisplay>>updateForm: aForm bounds: aBounds because if you go outside of form's bounds, you have imminent crash due to memory corruption. What can be done, code can be rewritten to take into account a canvas clipping + origin, to get more correct (and safe) copying of rendered pixels, but still avoiding extra copy to intermediate form. Anyways, i don't like the fact that it copying the rendered stuff from video memory back to main memory, and then copying stuff back to video memory (but this time by morphic + VM). But this was a cheap way to get demo working and morphic integration. If i would be making app which using opengl for rendering, i would never copy things like that, because it just a waste of cycles causing a big impact to frame rate. What works for demo, is not really applicable in serious application. Â :) In serious app, i'd rather copy morphic Display form into separate texture and then render it along with other Â stuff, which is already in video memory. But this approach needs more time investments, which currently i don't have, and actually heavily depends on what you want from your app. Anyways, if there's someone who having spare time to fix NBGLDisplay>>updateForm:bounds: implementation to make it safer, i would appreciate that. -- Best regards, Igor Stasenko.

Feb. 24, 2012

Re: [Pharo-project] loading a SLICE

by Bernardo Ezequiel Contreras

No, AFAIK when you load a slice, it loads the dependencies. take into account that my image is not broken On Thu, Feb 23, 2012 at 7:57 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > In my (broken ?) image, loading a SLICE does not load the > dependencies... Is it expected ? > Merging does merge the dependencies though... > > Nicolas > >

Feb. 24, 2012