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

Re: [Pharo-project] smalltalk color-print-style on a web page

by Igor Stasenko

On 9 February 2011 05:05, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > > I want to put smalltalk code with syntax coloring as it is > > http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > > on my web page > http://appdal.com/groups/36442/wiki/bbd28/Pharo_comment_of_the_day_contest.… > AFAIK, it is not smalltalk color highlighting. I don't know what syntax a google wiki takes for doing code highlight, but it is definitely not for smalltalk syntax. > Best Regards > -- > View this message in context: http://forum.world.st/smalltalk-color-print-style-on-a-web-page-tp3296588p3… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

Feb. 9, 2011

[Pharo-project] IWST @ ESUG 2011 call for papers

by Alain Plantec

------------------------------------------------------------------------------------------------------------------------ IWST @ ESUG 2011 International Workshop on Smalltalk Technologies August 23th, 2011 Edinburgh, Scotland http://www.esug.org/Conferences/2011/International-Workshop-on-Smalltalk-Te… CALL FOR PAPERS SUBMISSION DEADLINE : June 17, 2011 ------------------------------------------------------------------------------------------------------------------------ ESUG 2011 Smalltalk joint event IMPORTANT DATES * Submission deadline: June 17, 2011 * Notification deadline: July 15, 2011 GOALS AND SCOPE We are proud to invite submisssions to the International Workshop on Smalltalk Technologies which is held as part of the ESUG 2011 joint event at Edinburgh. The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. Participants are invited to submit short and not-so short research articles. We will not enforce any length restriction. However we expect papers of two kinds: * Short position papers describing emerging ideas. * Long research papers with deeper description of experiments and of research results. TOPICS We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: * Aspect-oriented programming, * Meta-programming and Meta-modeling, * Frameworks, * Interaction with other languages, * Implementation, new dialects or languages implemented in Smalltalk, * Tools, * Design patterns, * Experience reports PUBLICATION Pending ACM approval for Digital Library. Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm; this site also contains links to useful informations on how to write effective submissions. PROGRAM CHAIRS: * LoÃ¯c Lagadec (Labsticc, University of Brest, France) * Alain Plantec (Lisyc, University of Brest, France) PROGRAM COMMITTEE: * Gabriela Arevalo * Marcus Denker * Johan Fabry * Lukas Renggli * Hernan Wilkinson * Damien Cassou * Alexandre Bergel * Jordi Delgado * Johan Brichau

Feb. 9, 2011

[Pharo-project] about FS: a roadmap

by StÃ©phane Ducasse

HI guys I was rambling.... so I looked at other frameworks (RIO, FileMan) and I prefer FS. So I will start to write again comments, continue to reorganize the current structure. I was in contact with colin that told me that he found the improved version that he was doing after ESUG. I asked him to publish it into filesystem I will integrate the fixes of damien. I would like to have - a better help (already there). - Rename workingDirectory as workingDirectoryPath - add workingDirectory returning a FSReference - Every method with an adequate comment. The idea is that the comment should describe what the method does when we do not see its body: let us try to think a bit in JavaDoc or Ruby Yard fashion for once. - Use rename primitives - Have the possibility to create empty file - Clean identification of implementation tests and black box tests - Integrate Gemstone fixes - Stream usage clearly identified to support Gemstone migration) - Onion like structure so that we can have one or two packages that are really the core (yes I still want a minimal kernel). - Check the file API creation: old, new, exist.... - Prepare a migration path for 1.3 - Fix filesystem workingDirectory isWorkingDirectory returns false. - rename fileDoesNotExist: and friends do convey that its goal is mainly to raise en exception raiseFileDoesNotExistsFor: Of course I would like to avoid to throw away all that good energy so I hope to collaborate with colin. We will see what will happen. I can understand that he has another agenda/time frame but we should move on this front. So all my code will be publicly available in the SqueakSource/fs repository. If you think that this is the wrong path, let me know. I will report my changes regularly. Stef

Feb. 9, 2011

Re: [Pharo-project] Status of Alien

by Schwab,Wilhelm K

Eliot, I was referring to the overall design; so far it seems like a nice way to put the image in charge of thread management. The details of binding would not matter too much; I'm simply trying to get a handle on how it will look. Having a primitive to manipulate the threadid makes sense. Are there constraints on when it can be invoked? Can the Process be running at the time? Thinking in terms of how the Smalltalk code will look, I am wondering whether there should be a #forkAt:threadID: to allow a new process to "wake up" with the correct threadid?? How does one start a new thread? Is the result represented only by ID, or is it wrapped by something that is finalized? What about image saves and startup/shutdown while a bound process is running? In fairness, I am not certain I ever asked those questions about Dolphin's implementation. Putting calls on a background thread was mostly a way to protect my software from being frozen by long operations that either finished during the session or did not - it happened mostly in deployed executables so, when the background calls were needed, there was no concept of saving an image. A Process being unbound means it will run on any thread? Have you thought about binding everything to the GUI thread by default? Maybe I did Windows programming for too long, but undocumented thread affinities might not matter in that case, and if there's little harm, it might be a safer default. You and Andreas are probably the ones to hash that out though. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Tuesday, February 08, 2011 11:28 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien On Tue, Feb 8, 2011 at 7:01 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, I'm impressed :) To say that I truly understand would be dishonest, but I think I more or less get it. How is the binding of a Process to a thread done - I guess I am really asking what it looks like in code? One choice would be class side messages to ProcessScheduler or similar that return handles to or wrappers for the threads (#gui and #newThread come to mind), and those could be provided to a new process to bind it. Am I close? There's an instance variable in Process, threadId, that is nil (unbound) or holds the threadId of the thread it can run on. There is one primitive to bind it to the current thread and one to unbind. It is unsafe to manipulate the threadId inst var directly. It sounds like a really nice solution to the problem. The overall scheme or the thread-to-process mapping? best, Eliot Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>] Sent: Tuesday, February 08, 2011 8:57 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Status of Alien On Tue, Feb 8, 2011 at 5:45 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>>> wrote: Eliot, No lack of patience implied: just mentioning some things that I have picked up as off in the future and that would make us all stronger. Re the calls on OS threads, that is GREAT news. What strategy are you using to assign calls to the threads? I ask because there is a tradeoff between using a pool and taking what is ready to go, and coping with thread affinity. Example: OpenSSL is "easy" to call if one uses blocking calls and simply moves them out of the main thread (at least it worked for me on Dolphin). When I did this, I had to write a wrapper DLL to combined calls (connect, read, send, etc.) and checks for error status because otherwise, Dolphin would typically use different threads for the calls and the error test call was meaningless. IIRC, now they always use the same OS thread for any given Smalltalk Process - I think. There is no pool. Instead, arbitrary threads can run the VM, but only one at a time. So the strategy to control calls is to decide which processes are bound to which threads. A new Smalltalk process can be executed by any thread. There is a well-known thread id for "the GUI thread" and it may be necessary to have more. So to arrange that a call is made on the GUI thread one arranges that the cal is made from a Smalltalk process that is bound to the GUI thread. To arrange that calls are made form some specific thread once again one binds one or more processes to that thread and makes calls from those processes. The VM's Smalltalk scheduler is modified to do a thread switch when a process switch is made to a process bound to other than the current thread (i.e. it is now a classic two-level scheduler). Hence scheduling semantics don't change; it is still a real-time scheduler that always runs the highest-priority runnable Smalltalk process. Its just that under the covers an implicit thread switch might also occur when a process switch occurs. Make sense? best Eliot I fixed a few more things that have been pinning me to my hacked vms, so I will hopefully be able to more easily experiment. I will look around for Alien on Linux and give it a try if I find it. I am also looking forward to running my "real" images through Cog. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>>] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com><mailto:eliot.miranda@gmail.com<mailto:eliot.miranda@gmail.com>>] Sent: Tuesday, February 08, 2011 11:19 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>> Cc: Squeak Virtual Machine Development Discussion Subject: Re: [Pharo-project] Status of Alien On Tue, Feb 8, 2011 at 4:16 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>>>> wrote: Torsten, I have been under the impression that it has never worked on Linux - it would be great to be wrong on that. Does anyone have Alien on Linux waiting for someone to try it? I would be very surprised if it didn't work. We at least use the data manipulation side of things routinely at Teleplace. One thing slowing my search for FFI/Alien improvements has been that I was initially dependent on some vm modifications that I made. Some off-line correspondence with Dave Lewis and the benefit of some time might have yielded a solution that will let me return to stock vms. I need to integrate my new callback support and the ReentrantFFIPlugin into the standard interpreter as soon as possible. The ReentrantFFIPlugin provides compatibility with the old squeak FFI plugin but also allows aliens to be passed as arguments, at least to the extent of passing Alien Callbacks. This means its possible to discard the Alien callout support and use the FFI instead (but just to reiterate to keep the Alien data representation and callback facilities). The project for the next few weekends has to be harmonising the primitive set and functionality of Cog and the standard interpreter now that the StackToRegisterMappingCogit looks complete. FFI has generally worked for me. I am doing a horrible job of handling double arrays, but I am at least able to use them. My "solution" makes assumptions about byte order and I have declare double* as void*. There was mention of extending FFI with callbacks. Given that capability, the only thing missing would then to be make calls on OS threads to avoid blocking the image (but blocking the calling Smalltalk Process for the duration of the call). I have this in prototype and want to release soon. But there is too much else going on right now. Patience please. best Eliot Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>>> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>>>] On Behalf Of Torsten Bergmann [astares(a)gmx.de<mailto:astares@gmx.de><mailto:astares@gmx.de<mailto:astares@gmx.de>><mailto:astares@gmx.de<mailto:astares@gmx.de><mailto:astares@gmx.de<mailto:astares@gmx.de>>>] Sent: Tuesday, February 08, 2011 4:04 AM To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr><mailto:pharo-project@lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr>><mailto:pharo-project@lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr><mailto:pharo-project@lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr>>> Subject: [Pharo-project] Status of Alien What is the status of Alien. According to http://bugs.squeak.org/view.php?id=7475 there is no one who confirmed it working on Linux. Any news here? Any ideas on FFI/Alien successor? Thanks T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

Feb. 9, 2011

Re: [Pharo-project] Draft chapter on Settings Framework for PBE2 now online

by StÃ©phane Ducasse

thanks oscar! It will force us (alain and me) to have a look at it during our coding week at Roscoff. :) Stef On Feb 8, 2011, at 10:33 AM, Oscar Nierstrasz wrote: > > Hi Folks, > > There is now a draft chapter on the Settings Framework for "Pharo by Example 2" available for review: > > https://gforge.inria.fr/frs/download.php/28243/Settings.pdf > > http://pharobyexample.org/ > > Cheers, > - on > >

Feb. 9, 2011

Re: [Pharo-project] INRIA-CEA-EDF Deep into Smalltalk School registration open

by StÃ©phane Ducasse

Hi guys just a note to mention that the registration will be closed by 22 for internal administrative reasons. So pay attention. If you have a problem lets me know. Stef On Jan 12, 2011, at 10:02 AM, stephane ducasse wrote: > I forgot to say that ESUG will sponsor this event and can hel you financially. > Please address your request to me. > > Stef > > On Jan 12, 2011, at 10:01 AM, StÃ©phane Ducasse wrote: > >> The registration for the school: deep on Smalltalk organized at INRIA Lille Nord Europe is now open. >> http://www.inria.fr/centre-de-recherche-inria/lille-nord-europe/agenda/smal… >> >> Please register as soon as possible so that we can build some estimates. >> Please register even if you are local or close. >> >> ==== SCHOOL >> >> The objective of this school is to present on advanced Smalltalk topics such as compiler compiler, virtual machine, interaction with C, advanced UI, ... >> The school is structured around two main lectures on Virtual machines and a hand on sessions. >> â¢ Igor Stasenko RMOD Lille France >> â¢ Dr. Noury Bouraqadi >> â¢ Henrik Johansen Norway >> â¢ Jorge Ressia SCG Bern Switzerland >> â¢ Marcus Denker RMOD Lille France >> â¢ Prof. Theo D'Hondt VUB Belgium >> â¢ Dr. Tudor Girba Switzerland >> â¢ Dr. Eliot Miranda US >> >> â¢ Date : du 7 mars 2011 au 11 mars 2011 >> â¢ Lieu : Centre de recherche INRIA Lille Nord Europe >> >> ***There will be certainly a Pharo Sprint the saturday 15 of March. You are welcomed *** >> >> http://www.inria.fr/centre-de-recherche-inria/lille-nord-europe/agenda/smal… >> >> HOTEL >> ==== >> I'm negotiating with some hotels to provide fast a list. >> Now the first hotel that is cheap and good and that agreed to get better rooms >> for the same price is Hotel Agora >> 14 r Molinel 59000 LILLE >> Mail : agorahotel(a)yahoo.fr. >> 03 20 31 55 52 >> fax :.03 20 06 27 54 >> You should mention that you are coming to INRIA to get reduction. >> >> Stef >

Feb. 9, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #25 on issue 3583 by tudor.gi...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 This is an important fix. Benjamin, could you create a slice?

Feb. 9, 2011

Re: [Pharo-project] Issue 3659 in pharo: Task bar appearance does not make sense

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.2 Milestone-1.3 Comment #13 on issue 3659 by tudor.gi...(a)gmail.com: Task bar appearance does not make sense http://code.google.com/p/pharo/issues/detail?id=3659 Ok, I changed the milestone.

Feb. 9, 2011

Re: [Pharo-project] Issue 3659 in pharo: Task bar appearance does not make sense

by pharo＠googlecode.com

Comment #12 on issue 3659 by stephane...(a)gmail.com: Task bar appearance does not make sense http://code.google.com/p/pharo/issues/detail?id=3659 in 1.3 then.

Feb. 9, 2011

Re: [Pharo-project] Issue 3659 in pharo: Task bar appearance does not make sense

by pharo＠googlecode.com

Comment #11 on issue 3659 by tudor.gi...(a)gmail.com: Task bar appearance does not make sense http://code.google.com/p/pharo/issues/detail?id=3659 No, it's not. It affects UITheme. It should be integrated in Pharo Core.

Feb. 9, 2011