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

Re: [Pharo-project] Athens OpenGL backend - what does it mean?

by Sebastian Nozzi

2012/11/25 dimitris chloupis <thekilon(a)yahoo.co.uk>: > 240 commits later we had a morphic > interface for blender written in python and ported to bgl so it could run > from inside the blender window. I'm trying to understand... was it an alternative interface for Blender, or an interface toolkit just happening to sit on top of Blender? (or both?) > Suprisingly we did not have so much problem > with out own bugs but bgl proven too slow , buggy and unreliable so I had to > abandon because I could only solve that problem with hacking blender source > which is written in C and is almost not commented at all. Lets say here I am > no big fan of C language of Blender source. I begin to understand what you meant with "only thing it worries me is the type of technical blocks / obstacles I may come across". > Here you can find if you are interested the final blender python code ---> > https://github.com/kilon/EphestosOld What really would interest me is your personal opinion on Smalltalk as somebody coming from a Python background. That is, once you have more experience with it (Smalltalk). I don't know much Python, but considered it more than once because of something I didn't find in other mainstream languages that I would miss from Smalltalk: named parameters. Of course in Smalltalk you don't have that, since the method signatures give you that for free ;-) > From there on I was just searching for a home for Ephestos. I has quite > reluctant to join pharo because of the lack of developers and because I am > not that familiar with smalltalk as much I am with python. To be frank I am > not that motivated to join a language that is has a very small community > because of bug fixes and library support. I understand you completely and it is good to read this loud and clear. For every person like you that communicates this in a clear way there must be hundreds that consider Smalltalk and then discard it for the same (or other) reasons; the input never reaching the community. I would be tempted to tell you that being such a small community also has its advantages ;-) but I don't want to trivialize the issue. Smalltalk's community *is* very small, and the library support... well... could (and hopefully will) be better. In some areas, let's be honest, we are years behind other platforms/environments/languages. But why does a Smalltalk community still exists at all, then? Because yet in many other areas, Smalltalk is still *ahead* of anything else out there also for years if not for decades. Yes, I think this is a vital issue, and kind of a chicken-egg problem that needs to be solved (I know, it *is* being solved). In fact, I think I will write another mail asking this "small" (?) community what they think about it. > I actually even looked into common > lisp and emacs very recently as well since I really like lisp as a language > and I prefer from smalltalk. Conceptually I find Lisp also very interesting. But anytime I evaluate going the Lisp route I find myself planning to reach first some Lisp-based-Smalltalk syntax & semantics and then I say: why waste my time if there *is* already Smalltalk, waiting to be used? :-) At the end, I think the right approach to DSL (domain-specific-languages) nirvana will be the idea presented by the Helvetia project, incidentally also Smalltalk-based: http://scg.unibe.ch/research/helvetia > But it has become obvious to me that what I am trying to do for Ephestos is > synonymous to what smalltalk is trying to do, to offer a live visual > environment that makes code , fun , flexible and efficient. Cool :-) > So I decided to > take the deep dive into pharo. Smalltalk may not be super popular as python Not for a long shot, unfortunately. We as the Smalltalk community should be very sincere and evaluate, with a cool head, why this is so. > but porting all smalltalk stuff or even just little to python is just insane > amount of work so I think I made the sensible choice to port my project to > Pharo because it was already based on pharo libraries anyway. I don't get it... which part will you port from Python to Smalltalk, and which part you don't need/want to port? > Saying that I am still interested in offering some Blender support for > Ephestos and thus making pharo able to quickly communicate with blender And Blender would... render 3d? (whilst the interface would be on the Pharo side?) > probably via a socket bridge. The idea of (socket) "brides" to other languages / runtimes always made sense to me. At least short-term to break the library/devs cycle. I don't know if this idea was evaluated by the community. Recently there was an announcement of a bridge to a XUL (Mozilla) -based frontend, with Smalltalk back-end, using Seaside's continuations. So it should be easier as ever. > I got all these crazy ideas but I am willing > to take them a step at a time , so that is why I talked about "decades". I very much liked what Stef wrote yesterday, it got me thinking: start small and work steadily... Good to see that you have such long-term plans! :-) Best regards, Sebastian

Nov. 26, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Camillo Bruni

On 2012-11-26, at 12:45, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 November 2012 16:27, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> >>>> it's funny to see, but even when you gave your demo even you couldn't type >>>> the pragma definition yourself, so how do you except this to affect newcomers? >>> >>> no need to convince me. >>> of course i can type it.. but most of the time you copy/paster it from >>> method to method. >> >> of course you can copy paste it, but if you can avoid it at all, why would >> you even bother copy pasting? >> >> besides your opal solution will be ready in > 2 months. >> Actually we simply have to add a proper UI handler for the exception you >> throw when there is no primitive installed. You let the programmer decide >> what to do => 100% safe > > it is your call. do it if you want it so badly :) yup I put it on ym todo

Nov. 26, 2012

[Pharo-project] [update 2.0] #20418

by Marcus Denker

20418 ----- Issue 6973: two ClassDescription>> #correspondingForTest issues http://code.google.com/p/pharo/issues/detail?id=6973 Issue 7057: Add Special Inspectors For Floats and Integers http://code.google.com/p/pharo/issues/detail?id=705 Issue 7052: Fix in PolyMorph + TextHighlight fix http://code.google.com/p/pharo/issues/detail?id=7052 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.990.diff http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-MarcusDenker.737.diff http://ss3.gemstone.com/ss/Pharo20/Polymorph-Tools-Diff-MarcusDenker.83.diff http://ss3.gemstone.com/ss/Pharo20/NautilusCommon-MarcusDenker.104.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1293.diff -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Nov. 26, 2012

Re: [Pharo-project] MongoTalk update

by Yanni Chiu

On 25/11/12 5:04 AM, Fernando Olivero wrote: > Hi, this seems to answer your question. > > http://articles.tulipemoutarde.be/embedded-document-with-voyage-in-mongodb The model in that article has a one-to-many relation between a Spaceship and Pilots. The Pilot isPersistent/isRoot, so has its own MongoDB collection. IIUC, if Pilot were not persistent/root, then the collection of pilots would be serialized along with the Spaceship object, and there would be no separate Pilot collection in MongeDB. So my question is, how does MongoTalk handle the editing of the pilot collection, when it's embedded into the Spaceship. For example, if a pilot is added, removed, or updated, does the entire embedded collection get re-saved, or does a suitable MongoDB update query get generated?

Nov. 26, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Igor Stasenko

On 26 November 2012 16:27, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> it's funny to see, but even when you gave your demo even you couldn't type >>> the pragma definition yourself, so how do you except this to affect newcomers? >> >> no need to convince me. >> of course i can type it.. but most of the time you copy/paster it from >> method to method. > > of course you can copy paste it, but if you can avoid it at all, why would > you even bother copy pasting? > > besides your opal solution will be ready in > 2 months. > Actually we simply have to add a proper UI handler for the exception you > throw when there is no primitive installed. You let the programmer decide > what to do => 100% safe it is your call. do it if you want it so badly :) -- Best regards, Igor Stasenko.

Nov. 26, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Camillo Bruni

>> >> it's funny to see, but even when you gave your demo even you couldn't type >> the pragma definition yourself, so how do you except this to affect newcomers? > > no need to convince me. > of course i can type it.. but most of the time you copy/paster it from > method to method. of course you can copy paste it, but if you can avoid it at all, why would you even bother copy pasting? besides your opal solution will be ready in > 2 months. Actually we simply have to add a proper UI handler for the exception you throw when there is no primitive installed. You let the programmer decide what to do => 100% safe

Nov. 26, 2012

Re: [Pharo-project] dumpfs - inspecting floating point numbers

by Sven Van Caekenberghe

http://code.google.com/p/pharo/issues/detail?id=7057 On 25 Nov 2012, at 19:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 25 Nov 2012, at 18:11, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Good idea >> >> 2012/11/25 Camillo Bruni <camillobruni(a)gmail.com>: >>> just adding a little custom inspector would do the job ;) >>> define Float>>#inspectorClass and add a new Inspector.. > > OK, I will try something simple to start with.

Nov. 26, 2012

Re: [Pharo-project] Tests coverage of basic packages

by Sven Van Caekenberghe

Spectacular ! -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 26 Nov 2012, at 13:58, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > I created a more complex form of the report with colors. For not fully > covered methods it tires to show what parts of the methods are not > executed. > > https://ci.inria.fr/pharo/view/Pharo%20Kernel%202.0/job/Pharo%20Kernel%202.… > > Cheers, > -- Pavel > > On Sun, Nov 25, 2012 at 4:56 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> I created a Jenkins job [1] that tries to measure tests coverage of >> Pharo Kernel. So if you want to see how good are we in this area for >> basic Pharo packages, see the latest report [2]. >> It is measured only by code simulation so the results are not perfect >> and complete but for basic information it may be sufficient. >> >> Of course take it as a small incentive to improve credibility of our image :-) >> >> [1] https://ci.inria.fr/pharo/view/Pharo%20Kernel%202.0/job/Pharo%20Kernel%202.… >> >> [2] https://ci.inria.fr/pharo/view/Pharo%20Kernel%202.0/job/Pharo%20Kernel%202.… >> >> Cheers, >> -- Pavel >

Nov. 26, 2012

Re: [Pharo-project] Tests coverage of basic packages

by Pavel Krivanek

I created a more complex form of the report with colors. For not fully covered methods it tires to show what parts of the methods are not executed. https://ci.inria.fr/pharo/view/Pharo%20Kernel%202.0/job/Pharo%20Kernel%202.… Cheers, -- Pavel On Sun, Nov 25, 2012 at 4:56 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I created a Jenkins job [1] that tries to measure tests coverage of > Pharo Kernel. So if you want to see how good are we in this area for > basic Pharo packages, see the latest report [2]. > It is measured only by code simulation so the results are not perfect > and complete but for basic information it may be sufficient. > > Of course take it as a small incentive to improve credibility of our image :-) > > [1] https://ci.inria.fr/pharo/view/Pharo%20Kernel%202.0/job/Pharo%20Kernel%202.… > > [2] https://ci.inria.fr/pharo/view/Pharo%20Kernel%202.0/job/Pharo%20Kernel%202.… > > Cheers, > -- Pavel

Nov. 26, 2012

Re: [Pharo-project] Athens, Nativeboost and Igor's gray hair

by Esteban Lorenzano

sorry, but I did not :( On Nov 24, 2012, at 1:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello > > Very cool! > > Maybe you have built Chipmunk for Windows? (for people who stay out from C compiling). I can't find version compiled with -FFI flag. > > Best regards, > Denis > > 2012/11/22 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > Last week I've been sick, and because of that I've been bored. To get some fun I started to learn NativeBoos and Athens (and to stress Igor's patience on explain things :). > > After all, I prototyped a couple of examples that I think are fun: > > 1) AthensPlayground. This is a workspace prepared to fast-prototype athens animations (taking the same idea of http://www.processing.org/) > > You can see a video of the (for now) results here: http://youtu.be/NaR_fyk3qq4 > > I think it can be a good addition for people willing to do some animation work :) > > 2) After that, of course I was very happy, but I thought "why to stop there? now I want more!" and so, I made a quick search about physics library and after a couple of hours I made a (very primitive) Chipmunk usage framework and an even more primitive and simple "game engine like" framework, to mix both Athens and Chipmunk library. > > A video of the results can be found here: http://youtu.be/ZK-JlbeN09A > > Pretty cool, isn't? > > Ok, I know... is not like I invented the hot water, all of this was more or less present in morphic... but is cool to have real examples on using external libraries (also, physics are really hard to simulate, so... better to use something already existent). > > If you want to play with it, you can go to: http://smalltalkhub.com/#!/~estebanlm/Storm > > Enjoy :) > > Esteban > > > >

Nov. 26, 2012