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

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

[Pharo-project] Issue 3726 in pharo: Turn the orange corner into a real Morph object
by pharo＠googlecode.com March 21, 2011

March 21, 2011

Status: Fixed Owner: Benjamin...(a)gmail.com CC: siguc...(a)gmail.com New issue 3726 by Benjamin...(a)gmail.com: Turn the orange corner into a real Morph object http://code.google.com/p/pharo/issues/detail?id=3726 Gofer new squeaksource: 'PharoTaskForces'; package: 'AdorementMorph'; load Then add the attached cs. For now, it just cahnge the cursor into a hand ^^ But soon, we will attach behavior Attachments: Morphic-IgorStasenko.834.1.cs 1.8 KB

1 3

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource
by Marcus Denker March 21, 2011

March 21, 2011

On Mar 21, 2011, at 12:23 PM, Sven Van Caekenberghe wrote: > > On 21 Mar 2011, at 11:20, Bert Freudenberg wrote: > >> SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad. > > Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone. > However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that. > > Your other points a valid, of course. > > I think that "security" was not meant in the sense of accidentally loading wrong code. More in the sense that one could just delete all your code. Even though we have backups of the SqueakSource filesystem, you don't want that, as it would be a mess to repair. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] Issue 3834 in pharo: Add support for Threaded VMs in Process
by pharo＠googlecode.com March 21, 2011

March 21, 2011

Status: Accepted Owner: siguc...(a)gmail.com Labels: Milestone-1.3 Type-RequestForEnhancement Importance-High New issue 3834 by siguc...(a)gmail.com: Add support for Threaded VMs in Process http://code.google.com/p/pharo/issues/detail?id=3834 By Eliot: To enable threading you have to modify the Process class definition to include threadId as its fourth inst var and tell the VM of that fact by setting a bit in the image via vmParameterAt: (the below, also attached). Link subclass: #Process instanceVariableNames: 'suspendedContext priority myList threadId errorHandler name island env' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Processes'! SmalltalkImage methods for system attributes processHasThreadIdInstVar: aBoolean "The threaded VM needs to know if the 4th inst var of Process is threadId which it uses to control process-to-thread binding. This flag persists across snapshots, stored in the image header." aBoolean ifTrue: [self assert: (Process instVarNames at: 4) ='threadId']. self vmParameterAt: 48 put: ((self vmParameterAt: 48) bitClear: 1) + (aBoolean ifTrue: [1] ifFalse: [0]) e.g. "Ensure VM knows whether Process has threadId inst var or not." Smalltalk processHasThreadIdInstVar: (Process instVarNames includes: 'threadId'). Attachments: SmalltalkImage-processHasThreadIdInstVar.st 585 bytes

1 1