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

Re: [Pharo-project] Issue 3732 in pharo: default omni browser size bigger

by pharo＠googlecode.com

Comment #3 on issue 3732 by tudor.gi...(a)gmail.com: default omni browser size bigger http://code.google.com/p/pharo/issues/detail?id=3732 The fix seems to be here. In any case, I believe this is not a show stopper at all.

March 2, 2011

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by pharo＠googlecode.com

Comment #12 on issue 3620 by tudor.gi...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 As far as I understand, there is no simple solution. Could we not leave with this for 1.2?

March 2, 2011

Re: [Pharo-project] Issue 3706 in pharo: In OB: Text in comment pane of Browser uses syntax highlighting

by pharo＠googlecode.com

Updates: Cc: Benjamin.VanRyseghem.Pharo Comment #1 on issue 3706 by tudor.gi...(a)gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 Benjamin, I believe you are the most knowledgeable in this area. Would you have time to look into it?

March 2, 2011

Re: [Pharo-project] About RPackage

by Tudor Girba

Hi, On 2 Mar 2011, at 09:12, StÃ©phane Ducasse wrote: > > On Mar 1, 2011, at 11:06 PM, Tudor Girba wrote: > >> This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :). > > Ok I do not remember the protocol. > we should ask the PackageOrganizer to create a package? > or just to register it. The RPackage class>>named: is an internal method used only by the RPackageOrganizer for creating a package. If you want to ensure a package, you should use (I do not like the name :)): RPackageOrganizer>>registerPackageNamed: aSymbol ^ packages at: aSymbol asSymbol ifAbsentPut: [RPackage named: aSymbol] You can get to the default organizer via "RPackage organizer". So, something like: RPackage organizer registerPackageNamed: 'MyPackage' should do it. > I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it. > So in the PackageInfo logic there are two points; > - registration > - query/creation > > I have no problem to discard - query/creation > So to which of these two aspects are you referring to. In the current RPackage implementation, #named: is a method meant to be used only internally. The problem with tying creation to registration is that you cannot use multiple Organizers easily (this was the reason why we decoupled the two). What we could do is to rename #named: to #newWithName: and have named: be only a compatibility method that does: named: aString ^ RPackage organizer registerPackageNamed: aString Cheers, Doru > Stef > >> >> Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. >> >> Cheers, >> Doru >> >> >> On 1 Mar 2011, at 22:59, StÃ©phane Ducasse wrote: >> >>> Another point >>> >>> RPackage>>named: aString >>> >>> | newPackage | >>> newPackage := self new name: aString ;yourself. >>> "self organizer registerPackage: newPackage." >>> ^ newPackage >>> >>> does not register the package and this looks suspicion to me. >>> >>> >>> In addition I do not remember the exact logic but the pattern with PackageInfo is that >>> >>> PackageInfo named: #foo creates the package if it does exist >>> >>> PackageInfo class>>named: aString >>> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] >>> >>> So do you remember because it may be better to have the same creation protocol. >>> >>> Stef >>> >>> >>>> Hi cyrille/doru and others. >>>> >>>> I do not understand why >>>> RPackage organizer packages contains System? >>>> >>>> In fact all the categories are mapped to packages and I wonder why. >>>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >>>> but it means that in such a case we should merge categories to get back the package we have right now >>>> else we will end up with loading/saving problems. >>>> >>>> >>>> Stef >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> > > -- www.tudorgirba.com "Being happy is a matter of choice."

March 2, 2011

[Pharo-project] COG VM and Locale

by Hilaire Fernandes

I am still willing to get Locale working with the combination of COG VM and Pharo. especially to make a version of DrGeo for the XO laptop where the CPU is subminimal, it brings a big usability improvement for the kids. But so far, the locale plugin does not work, any clue? Hilaire

March 2, 2011

Re: [Pharo-project] Pharo 64-bit virtual machine?

by David T. Lewis

On Wed, Mar 02, 2011 at 04:14:31PM +0100, Friedrich Dominicus wrote: > Just wondering if anyone has build a 64-bit virtual machine for Pharo > Or are you sticking to 32-bit. If so how do you build the virtual > machine on a 64-bit system? Hi Friedrich, For a standard VM, you get a 64-bit VM just by compiling the VM on a 64-bit platform and not using the -m32 compiler flag. It works fine, but some plugins have not been updated to be 32/64 bit clean, so for most folks it is better to just use the 32-bit version. Personally, I usually use a VM compiled for 64-bit, but there is no real advantage to doing this. Additional info is at http://www.squeakvm.org/squeak64/faq.html. Dave

March 2, 2011

Re: [Pharo-project] Where to download

by Friedrich Dominicus

"Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> writes: > Friedrich, > > I recall having success with the vm as-is and just patching the image. > One thing the vm certainly should do is tell us the translations it > makes. I think it is always a good idea to know which port was > actually opened, or failed to open :) Double that for external > libraries, but that's another story. Sorry I wonder the primitive is placed in libSerialPlugin.a this are the function I found in the Content/Linux subdirectory e 08102f10 t primitiveSerialPortOpen 08102df0 t primitiveSerialPortRead 08102cc0 t primitiveSerialPortWrite 08105980 t primitiveSocketBindToPort 081055c0 t primitiveSocketConnectToPort 08104b40 t primitiveSocketListenOnPort 08104a00 t primitiveSocketListenOnPortBacklog 08104830 t primitiveSocketListenOnPortBacklogInterface 08104670 t primitiveSocketLocalPort 08103e60 t primitiveSocketRemotePort 08102630 t secCanConnectToPort 081025d0 t secCanListenOnPort 081034a0 T serialPortClose 081030d0 T serialPortInit 080d9a90 T serialPortMidiClockRate 08103210 T serialPortOpen 08103190 T serialPortReadInto 081030b0 T serialPortShutdown 08103120 T serialPortWriteFrom The code in Pharo is: <primitive: 'primitiveSerialPortOpenByName' module:'SerialPlugin'> So hasn't there a function with that name? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

March 2, 2011

Re: [Pharo-project] Where to download

by Friedrich Dominicus

"Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> writes: > Friedrich, > > I recall having success with the vm as-is and just patching the image. One thing the vm certainly should do is tell us the translations it makes. I think it is always a good idea to know which port was actually opened, or failed to open :) Double that for external libraries, but that's another story. > > Try the attached. It is basically lifted from Squeak (to handle > numbers and names) and then tweaked to avoid the silent failure trap. Thansk I'll try it tomorrow. Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

March 2, 2011

[Pharo-project] Pharo 64-bit virtual machine?

by Friedrich Dominicus

Just wondering if anyone has build a 64-bit virtual machine for Pharo Or are you sticking to 32-bit. If so how do you build the virtual machine on a 64-bit system? Regards Friedrich

March 2, 2011

[Pharo-project] [TODO 1.2] Things to do for 1.2

by Marcus Denker

Hi, I wonder if we will ever make it... Issues needed to be fixed for the Core Image: http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.2 Issues needed to be fixed for the Full Image: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 2, 2011