January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Voyage backends

by Esteban Lorenzano

Ho Torsten, wellâ¦ I planned Riak and maybe Tokyo and Omnibase (but when I find the timeâ¦ not much this days). I never thought about UnQLite (and also I never hear about it before :P ) cheers, Esteban On 16 Jan 2014, at 14:03, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Esteban, > > if I understood correctly Voyage is primarily an abstraction layer to access > NoSQL databases. Currently MongoDB or the image can be used as a backend. > > Are there any other backends available or planned (for instance to UnQLite using > PUnqlite [1]). > > As UnQLite is an embeddable database of really small size I guess it will be > as sucessful for the NoSQL world as SQlite3 was for the relation DBMS world > and supporting it as one possible backend for Voyage might be a real plus. > > At least I see that MongoDB is 102MB to install before one can use it and > unqlite library [2] is only a few KB ;) > So it is easier to package, deploy, ... - I havent checked the other features > of Mongo vs. PunQlite so far. > > Any comments about backends in general or UnQlite in particular? > > Thx > T. > > [1] http://forum.world.st/ANN-PunQLite-a-new-NoSQL-wrapper-for-Pharo-td4732162.… > [2] https://github.com/mumez/PunQLite/tree/master/binary

Jan. 16, 2014

Voyage backends

by Torsten Bergmann

Hi Esteban, if I understood correctly Voyage is primarily an abstraction layer to access NoSQL databases. Currently MongoDB or the image can be used as a backend. Are there any other backends available or planned (for instance to UnQLite using PUnqlite [1]). As UnQLite is an embeddable database of really small size I guess it will be as sucessful for the NoSQL world as SQlite3 was for the relation DBMS world and supporting it as one possible backend for Voyage might be a real plus. At least I see that MongoDB is 102MB to install before one can use it and unqlite library [2] is only a few KB ;) So it is easier to package, deploy, ... - I havent checked the other features of Mongo vs. PunQlite so far. Any comments about backends in general or UnQlite in particular? Thx T. [1] http://forum.world.st/ANN-PunQLite-a-new-NoSQL-wrapper-for-Pharo-td4732162.… [2] https://github.com/mumez/PunQLite/tree/master/binary

Jan. 16, 2014

Re: [Pharo-dev] [ANN] Pillar release 0.6

by Norbert Hartl

Am 15.01.2014 um 18:17 schrieb Damien Cassou <damien.cassou(a)gmail.com>: > Dear lists, > > I'm proud to announce the 0.6 release of Pillar, a syntax and > associated tools to write and generate documentation and books. > Great! This sounds really useful. I need to check this out. > Pillar is currently used to write the Enterprise Pharo book > (https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/) > and other projects. > Btw. the chapters 9 and 11 are nearly duplicates. Well done, norbert > The attached screenshot shows a part of the Voyage documentation > generated by Pillar (from > https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english/bl…) > > Pillar has many features: > - simple markup-based syntax with references, tables, pictures, > captions... (this is the syntax of Pier) > - export to HTML, LaTeX and markdown (more to come) > - customization of the export through a dedicated STON configuration file > - support of templates using the Mustache templating engine > - syntax-highlighting of generated code blocks (not yet in LaTeX) > - configurable numbering of section titles and figures > - ... > > Pillar has also: > - a 5-minutes tutorial > (https://github.com/DamienCassou/pillar-documentation/blob/master/README.md#…) > - a documentation > (https://github.com/DamienCassou/pillar-documentation) (in progress) > - a good test coverage (91% with more than a 1000 executed tests) > - a continuous integration job > (https://ci.inria.fr/pharo-contribution/job/Pillar/) > - a command-line interface > (https://github.com/DamienCassou/pillar-documentation#5--command-line-interf…) > - several existing use cases: > https://github.com/DamienCassou/pillar-documentation#6--example-pillar-usage > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > <pillar-voyage.png>_______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Jan. 16, 2014

Re: [Pharo-dev] how to debug NB?

by paolo.bernardi.67＠gmail.com

Il 15/01/2014 19.43, Igor Stasenko ha scritto: > > > > On 15 January 2014 17:58, paolo.bernardi.67(a)gmail.com > <mailto:paolo.bernardi.67@gmail.com> <paolo.bernardi.67(a)gmail.com > <mailto:paolo.bernardi.67@gmail.com>> wrote: > > Il 13/01/2014 2.25, Igor Stasenko ha scritto: > > > > > On 13 January 2014 00:08, paolo.bernardi.67(a)gmail.com > <mailto:paolo.bernardi.67@gmail.com> > <mailto:paolo.bernardi.67@gmail.com > <mailto:paolo.bernardi.67@gmail.com>> > <paolo.bernardi.67(a)gmail.com > <mailto:paolo.bernardi.67@gmail.com> > <mailto:paolo.bernardi.67@gmail.com > <mailto:paolo.bernardi.67@gmail.com>>> wrote: > > Il 12/01/2014 19.41, Igor Stasenko ha scritto: > > All i can say that callbacks for handling window > events need > special handling: > - you basically should prevent VM to do event > handling during > handling of event by callback. > > > Do I achieve that when starting in headless mode? > (no ui, no messages...) > > nope. VM will still run event loop (in ioProcessEvents) and do > more or less the same things. > that is another reason, btw to bring event loop handling to > image level. > > -- > Best regards, > Igor Stasenko. > > > Could I prevent VM (as you say, Igor) do process events > using primitiveEventProcessingControl? > > I tried hacking > NBFFICallback >> pvtEnter:stackPointer:primitiveMethod: > > by disabling events before block execution > and enabling them after callback termination. > > Pharo still works for a while, then crashes. > > nice try.. > now i am out of ideas why else it would be crashing :) > > > -- > Best regards, > Igor Stasenko. maybe primitiveEventProcessingControl still could be the solution, vm should be already blinded (event processing disabled) when the cb is fired. My nice :) try, instead, just tried to blind vm when cb was already fired. Now I should try to blind vm _before_ any cb is fired. But I'm not sure wxWidgets has chances to ear (and processing) incoming OS events when the vm's thread is freezed.

Jan. 16, 2014

dependency of Roassal 2 visualized

by Alexandre Bergel

Hi! Just to share the result of a small experiment we did: https://www.facebook.com/photo.php?fbid=573528489400419&set=a.5735284794004… Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 16, 2014

Re: [Pharo-dev] Smalltalk Impact

by H. Hirzel

On 1/15/14, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 15 Jan 2014, at 09:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >> Etoys should have contributed to Squeak when they had the resources. >> To secure their own future. >> >> âWe are not payed to work on Squeakâ, that is what I got toldâ¦ Probably correct at that time... >> in a tone >> as if my questions was the dumbest question one could have asked. >> >> > In hindsight, I think that the more aggressive reaction I got, the more it > was a sign of me actually being right, but I did not understand that back > thanâ¦ Difference in philosophy and priorities. Many people assume you can build something new and well defined on an existing ground in spite of a lot of idiosyncrasies and inconsistencies. Just by wrapping and creating a DSL. But in Smalltalk the idiosyncrasies remain visible whereas in most cases you might hide them behind an API. > I just slowly and quietly despaired until I could not even sleep anymore at > night. And the history so far tells us that it is _a lot_ of clean up effort ..... Noteworthy however: Scratch is successful in spite of being built on a early version of Squeak. The situation of Etoys to the contrary is not so clear. A comparison needs to consider more factors than just the platform it is built on.... --Hannes

Jan. 16, 2014

Re: [Pharo-dev] Roassal Visualization for control flow graph issues

by Tudor Girba

Hi Clement, I am happy you see value in these specific tools and that you built your own. I strongly believe there is great potential for Pharo in showing how development can change dramatically when these custom tools become cheap, and I would want to collect examples that provide incentives for others to do the same. So now, I am even more interested in taking a look :) Could you point me to: - the way to setup the image (ideally with scripts starting from a Pharo 3.0 image) - the Spec tools and Roassal visualizations you built - some instances of how to trigger the inspectors and visualizations ? Cheers, Doru On Wed, Jan 15, 2014 at 9:45 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > Hello, > > I looked in the literature and there are a few paper about exactly the > visualization I want. > Examples: > a paper about Graph Layout for Code Flow Visualization > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.3748&rep=rep1&… > a bachelor thesis on java control flow graph visualization for compiler > optimization > http://ssw.jku.at/General/Staff/TW/Wuerthinger06Bachelor.pdf > > Perhaps at some point if we find a bachelor to hire in our team we could > ask him to implement such a visualization too (as they did for java > seemingly). > > But I looked at java's control flow graph I saw they would not increase > much my productivity compared to what I have now, back jumps are displayed > but not in a so good way. Therefore I'll use what I have now. However it > would be nice to have that to teach easily compiler optimizations to people. > > Doru, > > I *really* need dedicated tools but I have already built them myself. A > year ago, I didn't know about GTInspector and Moldable debugger, so I built > dedicated inspectors with the old inspector framework of Pharo, then as it > was not good enough I built new inspectors based on Spec, and I ported the > generic classes of these inspectors in Pharo 3. Specific subclasses of > these inspectors exist for my projects. For example, here's an inspector of > an object in memory (an object oriented pointer): > > [image: Images intÃ©grÃ©es 1] > > With on the left the current address in memory, then what field it is for > the object (which is the class MethodDictionary), then the address written > at this memory location, and the result of #printString sent to this new > address. > > The next tool I'm going to built is a read only debugger (I mean without > on the fly method edition) to step on x86 disassembled instructions and its > abstract representation (similar to R*egister Transfer Language > <http://fr.wikipedia.org/wiki/Register_Transfer_Language>)* I used in my > compilation chain. I discussed once with Andrei and it seems the moldable > debugger fits more in the case where you need to debug smalltalk code or at > least byte code dependent code. In my case I compile from AST to x86 > skipping the byte code so as far as I know it is quite hard to build a tool > with what you have. In addition, I'd like to plug the Spec inspectors I > built before, which may not be easy if I choose to build the additional > tools in Glamour. So the timing is not very good for tools in my projects. > > Thanks for offering your help anyway. > > > However the tool you showed on RB AST is really cool, especially that I > use all the time intermediate representations that could perfectly fit this > kind of inspectors (mostly graphs). But I prefer visualization like the one > of roassal. > > Regards > > > > > 2014/1/15 Marcus Denker <marcus.denker(a)inria.fr> > >> >> On 14 Jan 2014, at 22:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > >> > As far as I can see, the visualization is derived from source code. >> This can be seen as being similar to how an AST is derived from source >> code. The GTInspector already provides an implementation of understanding >> this mapping. For example, in an image with GTInspector (just download the >> Moose one for quick tests) do: >> > (Collection>>#collect:) parseTree inspect >> > >> > and you get a picture like the attached one. >> > <Inspector on a RBMethodNode (coll...ion).png> >> >> This is *very* impressiveâ¦ :-) >> >> Marcus >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 16, 2014

[FEEDBACK] Install Pharo on Windows

by Torsten Bergmann

Damien Cassou wrote: > What is Pharo for you? What would you like to see when you click on a > Pharo icon? A terminal saying that you didn't pass an image to the VM? > For me, the entry point to Pharo should be the launcher. Just like the > entry point to Eclipse is the workspace selector. +10 I agree with Damien and for sure Pharo is more than the development environment we all know of. Meanwhile it is also a whole universe of additional projects. The Pharo launcher is the gate to the Pharo world once installed. One can not only download and start the release images (2.0/3.0/...) of Pharo but also additional project images like Moose, Roassal, Seaside, ... Maybe if the initial list of images is empty the Launcher should suggest to help download and start the latest Pharo base image release. This may increase the first time experience, because not anybody knows about this tree structure on the right and selecting the correct image first. Always think of a newbee who has no glue about VM/images/metacello packages/CI/... but who downloads the installer. He should be guided up to a running image with a workspace where he can try his first baby steps like Transcript show: 'HelloPharoWorld' It is highly important that it is easy to get there, otherwise people will turn away easily. So first impression counts! Thanks Torsten

Jan. 16, 2014

Pharo3: Update 700

by Marcus Denker

Hi, Pharo3 just got it's 700th update. This is a record for any Pharo release yet (Pharo2 was released with just below 600 updates). Every update contains the code of 1-5 issues from the issue tracker. Fixes, improvements, but even completely new subsystems. So the number does not work at all as a metric ;-) On the issue tracker, we have 1930 closed issues tagged for Pharo3, but many more where evaluated and closed without that tag (e.g. concerning infrastructure). 68 cases where resolved the last 7 days alone (!!). In the issue tracker, we have still 51 issues for Pharo3 that are rated "must fix" or higher, but with the speed of bug fixing we see, we are very much on the road to have a very stable release in March. The issue tracker is at https://pharo.fogbugz.com

Jan. 16, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30700 Home: https://github.com/pharo-project/pharo-core

Jan. 16, 2014