- Pharo-dev - lists.pharo.org

Re: [Pharo-project] HwaJong Oh

by Noury Bouraqadi

On 20 sept. 2010, at 13:58, ë¬ë£ì¤íì¢ wrote: > Hi, > > i joined this mailinglist. > > I am Korean Hobby Smalltalker first time Europe first time ESUG. > > Hope you remember me. > Yes! And I remember you presentation during the "Show us your projects" session. It was cool. Hope to see again next ESUG conf, Noury ESUG Treasurer www.esug.org

Sept. 20, 2010

Re: [Pharo-project] MethodName is now Finder

by Marcus Denker

> > > I have a question...for the future of Pharo 1.2....what will happen with Method names and method finder? Will both of them removed and put instead this new finder? > I ask because I wonder if we need or not to include these packages in PharoCore... > So...in summary...all these changes will be part of core or is the dev also involved? > Core for now. And not as it's own package, but as part of the Tools package. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 20, 2010

Re: [Pharo-project] about events :)

by Mariano Martinez Peck

open ticket so that not to forget :) 2010/9/20 Guillermo Polito <guillermopolito(a)gmail.com> > Thinking aloud, How difficult can be to make #changed: and actionMaps use > Announcements as a first step? So we don't break the existing contract > changing the behavior :) > > But I'm talking from my ignorance, because I don't have in mind how all of > them works... > > > On Sun, Sep 19, 2010 at 9:11 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> +10 - Weak subscriptions are a must. Absent that, we'll end up with >> bloated images and lots of unhappy users. >> >> >> >> >> ________________________________________ >> 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: Sunday, September 19, 2010 8:01 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] about events :) >> >> On 19 September 2010 16:42, Juan Vuletich <juan(a)jvuletich.org> wrote: >> > StÃ©phane Ducasse wrote: >> >> >> >> hi >> >> may be I'm wrong but I have the impression that we have around three >> >> different kinds of event system in the system >> >> >> >> - actionMap >> >> - announcement >> >> - changed: >> >> Could we simplify that? >> >> Stef >> >> >> > >> > Yes! Kill #changed: And if you adopt announcements, kill actionMap too! >> > >> amen. >> But we have to add weak subscriptions to announcements first, >> otherwise you won't be able to >> properly reimplement actionMap/changed: without that. >> I provided some code for that, but i'm not sure if it integrated into >> pharo yet. >> >> > Cheers, >> > Juan Vuletich >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

Re: [Pharo-project] [Vm-dev] failing/errors Pharo Tests with CogVM

by Mariano Martinez Peck

Ok....that's to all the responses. The thread is now far away my knoweldege, so I will naively ask: is it worth creating a Pharo 1.1.1 one click with CogVM? Marcus released a PharoCore 1.1.1 with changes for CogVM and some important fixes. I took that core image and I created a new dev. But before releasing, I run the tests and I found them. Seems you all discussed about the Float problems...but what about the others? I remember them and I thing they were fixed in newest versions of VMMaker. So...the question is now....are the failure/error of those tests means that Pharo is "unreleasable" with CogVM? Should we wait for the fix or we should release anyway? Thanks in advance, Mariano On Fri, Sep 17, 2010 at 8:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Thu, Sep 16, 2010 at 10:54 PM, Andreas Raab <andreas.raab(a)gmx.de>wrote: > >> >> On 9/16/2010 2:44 PM, Eliot Miranda wrote: >> >>> I realise we need to be more precise. Are you talking about NaNs >>> specifically or NaN and Inf? >>> >> >> NaN only. +-Inf are fine as they have a well-defined mathematical >> relationship over the set of numbers. NaN does not. >> >> >> The Squeak VM happily answers Inf from its >>> float primitives. In fact the only guard against a NaN or Inf result >>> being produced by the floating-point primitives is the guard against >>> dividing by zero. But e.g. in the interpreter (1.0e300 / 1.0e-300) >>> isInfinite and there is no failure. So specifically failing for aFloat >>> / 0.0 seems a bit of a fig leaf to me. >>> >>> So what would your ideal semantics be? >>> a) - fail whenever the result is Inf or NaN? >>> b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer Inf >>> c) - fail whenever the result is NaN but fail aFloat / 0.0 >>> d) - the Interpreter status quo, fail only for aFloat / 0.0 >>> e) - never fail and answer Nan and Inf as specified in IEEE 754 >>> >>> The situation with VW before IEEE was that it did a) and we changed it >>> so that the mode switch selected either a) or e), with, IIRC, the >>> current default being e). >>> >> >> f) Fail whenever the result is NaN or when dividing by zero. >> > > OK, to be pedantic that's c) above. But fine. This is a reasonable choice. > > >> My preference for f) is that division by zero should be consistent between >> floating point numbers and integers. It would be strange if "1 / 0" => boom >> but "1.0 / 0" => Inf or "1 / 0.0" => Inf. *However* underflow isn't division >> by zero and may silently result in Inf. In other words: >> >> self should:[1.0 / 0.0] raise: ZeroDivide. >> >> but (#successor produces the smallest float larger than the receiver) >> >> self shouldnt:[1.0 / 0.0 successor] raise: Error. >> self assert: (1.0 / 0.0 successor) = Float infinity. >> >> Cheers, >> - Andreas >> > > >

Sept. 20, 2010

Re: [Pharo-project] MethodName is now Finder

by Mariano Martinez Peck

2010/9/19 Benjamin Van Ryseghem <benjamin.vanryseghem(a)gmail.com> > I've fix some bug and discover how to script packages loading ^^ > > Now, just run > > > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'ConfigurationOfFinder'; > load > > ConfigurationOfFinder loadDefault > So....you saw our talk with Dale? Hope that helped and don't hesistate to ask further questions. I have a question...for the future of Pharo 1.2....what will happen with Method names and method finder? Will both of them removed and put instead this new finder? I ask because I wonder if we need or not to include these packages in PharoCore... So...in summary...all these changes will be part of core or is the dev also involved? Cheers Mariano > > > > > Ben > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

Re: [Pharo-project] A pattern for GUI programming (Morphic, Cuis, etc)

by Alexandre Bergel

Maybe you can put it on the google code website... Alexandre On 19 Sep 2010, at 09:39, Juan Vuletich wrote: > Noury Bouraqadi wrote: >> Hi Juan, >> >> Is this document available somewhere on the web? It's important to ensure it is persistence. >> Noury >> > > Hi Noury, > > I'm glad you're interested on it. I'll put it in a web page maybe tonight, or in my next "free evening". > > Cheers, > Juan Vuletich > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 20, 2010

Re: [Pharo-project] Custom World menu for own apps

by Alain Plantec

thanks! Alain Le 20/09/2010 14:48, Torsten Bergmann a Ã©crit : > Just for the records: > > in Pharo 1.2. it is now possible to define an own custom pragma > that is used to define a world menu. This is especially usefull > when you create a (commercial) application based on Pharo. > > How it works: > ============= > > 1. Define your new world context menu by providing class methods > with your own custom world menu entries. Instead of using the > usual "worldMenu" pragma we use a custom pragma, here > "myAppWorldMenu": > > > menuCommandOn: aBuilder > <myAppWorldMenu> > (aBuilder item: #'About MyApp') > action: [ 'HelloWorld' inspect ]; > icon: ThemeIcons pharoIcon > > > 2. Switch the world state to use the custom pragram: > > WorldState desktopMenuTitle: 'My shiny App'. > WorldState desktopMenuPragmaKeyword: 'myAppWorldMenu' > > If you want the old one back just evaluate: > > WorldState desktopMenuTitle: 'World'. > WorldState desktopMenuPragmaKeyword: 'worldMenu' > > > Maybe someone can add this to the open pharo book or give me > an account, a short howto and time to include it. >

Sept. 20, 2010

Re: [Pharo-project] VM Plugins internal vs external

by Igor Stasenko

On 20 September 2010 12:51, Torsten Bergmann <astares(a)gmx.de> wrote: > >From what i know, it has more to do with having smaller sized vm's, than >with efficiency reasons. > > Yes, and with security. Thats why FFI is external. If you > remove it all code (downloaded or not) can only use built > in primitives and its not possible to call OS API's and > harm your computer. > Stop scaring the people, Torsten :) If you have an intent to damage the computer, you can do it even without FFI, since VM allows you to interact with OS'es file system. The only scenario, where you would not want to allow FFI is in sandboxed environment, like browser plugin, where you do not allow to interact with display, files, network directly. But then, i think, it is better to build a specialized VM for that, rather than trying to make the default VM, which is shipped by developers and for developers, so limiting that you can't do things which you intend to do anyways (see Teleplace, for example). > Bye > T. > > > > -- > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 20, 2010

Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b3.

by Damien Cassou

On Fri, Aug 27, 2010 at 9:59 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > It works now: I tried closing all open windows in the image and now it runs headless. I thought that wasn't necessary with other VMs but maybe I always did so without thinking about it. I confirm I had to close an open window in the image before being able to run with -vm-display-null. I tried with -sendtrace and got no result. If the window is not closed, nothing seems to happen. To reproduce on linux: 1) download http://hudson.lukas-renggli.ch/job/Pier%202/248/artifact/Pier-2.0-OneClick.… 2) unzip the file 3) cd into the directory 4) execute: ./Contents/Linux/squeakvm -plugins ./Contents/Linux -encoding latin1 -vm-display-null -vm-sound-null -sendtrace ./Contents/Resources/Pier.image the prompt is not returned to the user (which is ok), but 'http://localhost:8080/pier' does not answer. 5) press Ctrl-c to kill the vm 6) execute the same line and change -vm-display-null to -vm-display-X11 7) Pharo opens, close the Seaside adapters window 8) save your image 9) execute same line as in 4) now http://localhost:8080/pier displays the correct page. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 20, 2010

Re: [Pharo-project] VM Plugins internal vs external

by Igor Stasenko

Also, some of the plugins are meant to be internal for forever, since they are tightly bound with VM and its basic functionalities (files, bitblt etc). Some other plugins are meant to be only external, and they even not build if you try to build them as internal ones. On 20 September 2010 13:07, Alexander LazareviÄ <laza(a)blobworks.com> wrote: > Hi Noury! > > Well the internal plugins are part of the vm executable and the > external plugins are shipped as separate shared library files. The > interface to both variants is the same, but not every vm plugin might > work as an external or internal plugin depending on the > implementation. > I don't know if this is still true, but there was also the idea, that > an external plugin "overrides" an internal version. So in the case of > a malfunctioning internal plugin, you could ship a new external plugin > of the same name that will be used instead of the internal one when > placed in a location of the vm plugin paths. But that's all out of my > flaky memory and could be totally different nowadays.:) > > Alex > > 2010/9/20 Noury Bouraqadi <bouraqadi(a)gmail.com>: >> Hi, >> >> What is the difference between internal and external plugins in the VM? >> >> Noury >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 20, 2010