- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 1299 in pharo: OS Process Crash
by pharo＠googlecode.com March 21, 2011

March 21, 2011

Updates: Status: Closed Comment #8 on issue 1299 by marcus.d...(a)gmail.com: OS Process Crash http://code.google.com/p/pharo/issues/detail?id=1299 Can you re-test in the light of the 1.2 release and new VMs?

1 0

[Pharo-project] IWST @ ESUG 2011 call for papers
by Alain Plantec March 21, 2011

March 21, 2011

------------------------------------------------------------------------------------------------------------------------ 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 Authors of the best accepted papers will be invited to submit extended versions of their papers for publication in a special issue of 'Software: Practice and Experience' ------------------------------------------------------------------------------------------------------------------------ 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

1 1

[Pharo-project] Issue 3342 in pharo: have a look at sharedQueue fixes from Levente
by pharo＠googlecode.com March 21, 2011

March 21, 2011

Status: Accepted Owner: stephane.ducasse Labels: Milestone-1.3 Type-Squeak New issue 3342 by stephane.ducasse: have a look at sharedQueue fixes from Levente http://code.google.com/p/pharo/issues/detail?id=3342 Check the squeak mailing: the thread of 15 of november 2010: [squeak-dev] The Trunk: Kernel-ul.515.mcz Hi Folks, Please also restore Semaphore>>critical:ifLocked: It already includes this comment: "Note: The following is tricky and depends on the fact that the VM will not switch between processes while executing byte codes (process switches happen only in real sends). The following test is written carefully so that it will result in bytecodes only." To be more explicit, in Cuis it also says: "Do not change the following #== for #=, as #== is not a real message send, just a bytecode." It's unnecessary, because #= also has it's own bytecode in the current VM. So #= won't be a real message send in this case, because both excessSignals and 0 are SmallIntegers. Also, this method has a bug. There's no guarantee, that the sender won't wait for the semaphore. I uploaded a fix to the Inbox for review recently, though I didn't get any feedback on it: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-November/155058…

1 1

Re: [Pharo-project] Issue 3115 in pharo: better SharedQueue>>makeRoomAtEnd
by pharo＠googlecode.com March 21, 2011

March 21, 2011

Updates: Status: Invalid Comment #3 on issue 3115 by marcus.d...(a)gmail.com: better SharedQueue>>makeRoomAtEnd http://code.google.com/p/pharo/issues/detail?id=3115 Bit for Pharo as we use SharedQueue2...

1 0

Re: [Pharo-project] [squeak-dev] [UPD] NativeBoost runs on new Cog VMs
by Igor Stasenko March 21, 2011

March 21, 2011

On 21 March 2011 02:43, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sun, 20 Mar 2011, Igor Stasenko wrote: > >> Hello, >> i just wanna to inform you that i adopted NativeBoost plugin for >> building with latest Cog vms. > > Great. > >> >> To build VM, you should have an image with VMMaker + CMakeVMMaker >> packages installed. >> >> Then load NBIntaller package and do: >> NBInstaller installCogPlugin >> >> There are new cmake configurations i added to build VMs with NB plugin >> support. > > It's an old question, but I don't remember your answer, so: wouldn't it > be better to add a command line switch for enabling NB? So even if a VM is > compiled with NB, I can still turn it off if I want to. > It is disabled by default, when you starting a new image. This allows me to not care if some of the methods were carrying native code saved into an image. For enabling a native code, one should invoke #primitiveEnable first. You can customize a mechanism of enabling it in NativeBoost class>>enableNativeCode and put checking of command-line argument(s) there. And yes, i am against putting extra logic at plugin side :) The reason is simple: if you using it, then you know what you doing, and if you don't - then you safe anyways. Also, plugin can be made external, if you want. But there is certainly some intimate connection with VM, so i wouldn't recommend making it external, because it can easy break things, if you mismatch VM/plugin pairs. I am also looking forward for making JITted code to make direct calls to NB native code. In a way, that JIT code would not call #primitiveNativeCall (and only then enter native code) but instead directly call the native code which method contains. It will , of course, bypass all logic placed in #primitiveNativeCall, like checking if NB is enabled etc.. and could be dangerous.. but the speed will be... :) In a longer perspective this means that eventually JIT compiler could be moved from VM to language side (like Exupery does). -- Best regards, Igor Stasenko AKA sig.

2 6

Re: [Pharo-project] Issue 3108 in pharo: Project >> updateLocaleDependents dependent on MenuIcons
by pharo＠googlecode.com March 21, 2011

March 21, 2011

Updates: Status: Closed Comment #1 on issue 3108 by marcus.d...(a)gmail.com: Project >> updateLocaleDependents dependent on MenuIcons http://code.google.com/p/pharo/issues/detail?id=3108 This has been fixed

1 0

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.52.mcz
by Eliot Miranda March 21, 2011

March 21, 2011

On Sun, Mar 20, 2011 at 11:23 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > Am 2011-03-20 um 19:17 schrieb Eliot Miranda: > > > > > > > On Sun, Mar 20, 2011 at 11:15 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > > > Am 2011-03-20 um 19:09 schrieb Eliot Miranda: > > > > > ------- > > > Name: VMMaker-oscog.52 > > > Author: IgorStasenko > > > Time: 18 March 2011, 12:45:14 am > > > UUID: a2810aac-4423-6740-b70e-7e821b979cb4 > > > Ancestors: VMMaker-oscog-IgorStasenko.50, > > > VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 > > > > > > Merge with oscog-49-51 & Esteban-50 > > > ------- > > > > > > I feel like you continuously ignoring my requests to merge the code > > > base.. and work together on merged instance > > > of VMMaker. > > > If you don't like this code, just say it. But don't ignore. > > > > > > Its not intentional. It's simply a matter of finding time to do the > merge. Mariano posted a bug. I fixed just that bug and published. I'm not > dissing you. I have very limited time. > > > > > > > Hmm, wouldn't applying the âdefaultâ naming scheme prevent such > overwrites? > > > > That is, now there would be > > VMMaker-oscog-eem.52 > > for Elliots version and > > VMMaker-oscog-IgorStasenko.52 > > for Igors version. > > What would prevent us from that? > > > > I don't see a naming conflict. I've been using VMMaker-oscog.NN since > the beginning and Igor has been using VMMaker-oscog-IgorStasenko.NN. This > isn't about names, it's about content. Igor is miffed I didn't merge in > some changes he made when I published VMMaker-oscog.52, right Igor? > > > > No, youâobviously accidentallyâoverwrote his version of the 18th of March: > So how did Monticello allow me to do that? That's a /bad/ bug. > > >>> > Name: VMMaker-oscog.52 > Author: IgorStasenko > Time: 18 March 2011, 12:45:14 am > UUID: a2810aac-4423-6740-b70e-7e821b979cb4 > Ancestors: VMMaker-oscog-IgorStasenko.50, > VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 > > Merge with oscog-49-51 & Esteban-50 > <<<< > > which has the same file name as yours: > > >>> > Name: VMMaker-oscog.52 > Author: eem > Time: 20 March 2011, 9:31:20 am > UUID: 1241a856-8570-4725-a069-a6d3d8a8a222 > Ancestors: VMMaker-oscog.51 > > Fix primitiveFlushCacheByMethod for objects-as-methods. > <<<< > > Since oscog is, as far as I can see, a kind-of branch of the > âdefaultâ VM-Maker, I think adding the developer initial/name to > the Package name would be in the spirit of monticello idioms. > Except that its my branch and I've been using oscog from the start. Igor had no need to use the same name line as me. I don't want to change now. oscog refers to my branch of VMMaker for "open source Cog". cheers Eliot > > So Long, > -Tobias > > > >

7 9

[Pharo-project] Issue 3687 in pharo: Browse senders/implementors in Omnibrowser/OB pops up menu that doesn't respond to enter/CR
by pharo＠googlecode.com March 21, 2011

March 21, 2011

Status: New Owner: ---- New issue 3687 by ncalexan...(a)gmail.com: Browse senders/implementors in Omnibrowser/OB pops up menu that doesn't respond to enter/CR http://code.google.com/p/pharo/issues/detail?id=3687 Pharo image: Pharo Pharo core version: <12327> Class browser used (if applicable): <OBSystemBrowserAdaptor> Steps to reproduce: 1. open OB 2. select method in right-most pane 3. type Cmd-N for senders or Cmd-M for implementors 4. try to accept default in menu by hitting enter This is pretty bad for keyboard navigation.

4 12

[Pharo-project] Issue 3605 in pharo: [ENH]: Added #saveTo: method to MIMEDocument
by pharo＠googlecode.com March 21, 2011

March 21, 2011

Status: New Owner: ---- New issue 3605 by sean.p.d...(a)gmail.com: [ENH]: Added #saveTo: method to MIMEDocument http://code.google.com/p/pharo/issues/detail?id=3605 When downloading via Url classes, this makes it more straight-forward to save (an image for example), now: aUrl retrieveContents saveAs: savePath. instead of: FileStream forceNewFileNamed: anAbsolutePathString do: [ :str | str binary. str nextPutAll: (aUrl retrieveContents contents) ]. Attachments: MIMEDocument-saveAs.st 324 bytes

1 2

[Pharo-project] Issue 3591 in pharo: Implementors of #listMorph place it in different (or no) category
by pharo＠googlecode.com March 21, 2011

March 21, 2011

Status: New Owner: ---- New issue 3591 by sean.p.d...(a)gmail.com: Implementors of #listMorph place it in different (or no) category http://code.google.com/p/pharo/issues/detail?id=3591 Pharo1.2rc1 Latest update: #12320 What is (if any) the standard here? I usually follow Kent Beck's advice to put getters in 'private' unless they are meant to be public, and in that case, in 'accessing'. But here we have 'accessing'/'callbacks' (OB)/'user interface'. Sean

1 2