- Pharo-dev - lists.pharo.org

confused about the "image opening session"

by stepharo

Hi I saw that we have a new cool feature that presents changes that would have been loaded but not save in the image. Now I got confused because several times I prompted with this list and I do not see how I ended up having it since I save my image and did not get crash (or idea that I lost changes). Is it me that do not understand correctly this feature? At the minimum it would be nice to have a little bit more explanation about what is happening. Because I imagine new guys coming and seeing this list without any further explanation could be confused. Stef

July 5, 2016

Re: [Pharo-dev] Bug in MailA

by stepharo

tx Bernhard! Le 3/7/16 Ã 13:25, Bernhard Pieber a Ã©crit : > Done! > > Cheers, > Bernhard > >> Am 03.07.2016 um 00:08 schrieb Ben Coman <btc(a)openinworld.com>: >> >> On Sun, Jul 3, 2016 at 3:16 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>> Hi, >>> >>> The following code goes into an endless loop: >>> MailAddressParser addressesIn: 'romeo&julia@verona.itâ >>> >>> Itâs because of the ampersand. The fix is trivial, because the bug just was a typo. >>> >>> Fix and test are in the Pharo50Inbox: >>> Network-Mail-BernhardPieber.46.mcz >>> Network-Tests-BernhardPieber.14.mcz >>> >>> Cheers, >>> Bernhard >> Thanks Bernhard. >> Can you log an issue for it on >> and submit this in Slice format. >> Instructions at http://pharo.org/contribute-propose-fix >> This makes it easier to review and the integration system only works >> with Slices & Configurations. >> >> cheers -ben > >

July 5, 2016

Re: [Pharo-dev] ShortArray, DoubleArray & influence of 64bit

by ClÃ©ment Bera

Hi On Tue, Jul 5, 2016 at 4:21 PM, Thibault Raffaillac < thibault.raffaillac(a)inria.fr> wrote: > Hi all, > > For a few months now I have been using IntegerArray and FloatArray with > UFFI. They are pretty convenient since they reside in Internal memory space > (unlike FFIExternalArray) yet you can pass them in a C function call with > the "ByteArray" signature. > Now I need the equivalent arrays for short, double words and IEEE 64bit > double. Comment in > Class>>variableWordSubclass:instanceVariableNames:classVariableNames:package: > says Spur already supports them. From discussion with Guille it seems we > just need new subclasses of BitsLayout (ByteLayout and WordLayout > implemented so far). > > Question 1: What is the value of instanceSpecification for shorts and > double-words? > I copy the comment of Behavior>>instSpec *instSpec* * "Answer the instance specification part of the format that defines what kind of object* * an instance of the receiver is. The formats are* * 0 = 0 sized objects (UndefinedObject True False et al)* * 1 = non-indexable objects with inst vars (Point et al)* * 2 = indexable objects with no inst vars (Array et al)* * 3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al)* * 4 = weak indexable objects with inst vars (WeakArray et al)* * 5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron)* * 6 = unused* * 7 = immediates (SmallInteger, Character)* * 8 = unused* * 9 = 64-bit indexable* * 10-11 = 32-bit indexable (Bitmap)* * 12-15 = 16-bit indexable* * 16-23 = 8-bit indexable* * 24-31 = compiled methods (CompiledMethod)"* > > Question 2: Both IntegerArray and WordArray exist and refer to 32bit > arrays, should there be a difference between the two? > > Yes. IntegerArray has two specific accessing primitives to store and read raw integers. WordArray uses the normal accessing primitives. Question 3: How will it fare with 64bit Spur? Does word refer to 32bit or > 64bit then? Is WordArray/variableWordSubclass growing to 64bit? FloatArray > too? > It depends. ByteArray is a good name and ShortArray is good name, self-explanatory, there is no discussion here. Then it depends, at some place we use WordArray and DoubleWordArray, in other we use LongArray and SixtyFourBitsIndexableArray... I'd go for WordArray and DoubleWordArray, but I don't mind if one decides otherwise. For Float, we changed the representation to be "SmallFloat64" and "BoxedFloat64". We have no proper support for single precision float in Pharo. We could consider renaming FloatArray to DoubleArray, Float64Array, or something similar. I don't know. > Cheers, > Thibault > >

July 5, 2016

ShortArray, DoubleArray & influence of 64bit

by Thibault Raffaillac

Hi all, For a few months now I have been using IntegerArray and FloatArray with UFFI. They are pretty convenient since they reside in Internal memory space (unlike FFIExternalArray) yet you can pass them in a C function call with the "ByteArray" signature. Now I need the equivalent arrays for short, double words and IEEE 64bit double. Comment in Class>>variableWordSubclass:instanceVariableNames:classVariableNames:package: says Spur already supports them. From discussion with Guille it seems we just need new subclasses of BitsLayout (ByteLayout and WordLayout implemented so far). Question 1: What is the value of instanceSpecification for shorts and double-words? Question 2: Both IntegerArray and WordArray exist and refer to 32bit arrays, should there be a difference between the two? Question 3: How will it fare with 64bit Spur? Does word refer to 32bit or 64bit then? Is WordArray/variableWordSubclass growing to 64bit? FloatArray too? Cheers, Thibault

July 5, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60136 Home: https://github.com/pharo-project/pharo-core

July 5, 2016

[pharo-project/pharo-core] b6e101: 60136

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b6e10187712eed097508e9639e6691c2b0f3dfce https://github.com/pharo-project/pharo-core/commit/b6e10187712eed097508e963… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: R Collections-Abstract.package/SequenceableCollection.class/instance/copying/copyLast_.st M DebuggerModel.package/DebugSession.class/class/actions registration/debuggingActionsFromClass_forPragma_forDebugger_.st A Deprecated60.package/extension/Pragma/instance/method_.st A Deprecated60.package/extension/Pragma/instance/selector.st A Deprecated60.package/extension/SequenceableCollection/instance/copyLast_.st M GT-Playground.package/GTPlayground.class/instance/building actions/contextMenuActions.st R Kernel.package/Pragma.class/instance/accessing-method/selector.st M Keymapping-Pragmas.package/KMPragmaKeymapBuilder.class/instance/registrations handling/collectRegistrations.st M Keymapping-Pragmas.package/KMPragmaKeymapBuilder.class/instance/registrations handling/pragmaCollector.st M MenuRegistration.package/PragmaMenuBuilder.class/instance/registrations handling/collectRegistrations.st M MenuRegistration.package/PragmaMenuBuilder.class/instance/registrations handling/pragmaCollector.st M Metacello-Core.package/MetacelloAbstractVersionConstructor.class/instance/private/evaluatePragma_.st M Metacello-Core.package/MetacelloVersionConstructor.class/instance/private/defaultSymbolicVersionResolverBlock_.st R OpalCompiler-Core.package/extension/Pragma/instance/method_.st M PragmaCollector.package/PragmaCollector.class/instance/system changes/addedEventOccurs_.st M PragmaCollector.package/PragmaCollector.class/instance/system changes/modifiedEventOccurs_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60135.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60136.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60135.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60136.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Changes-FileServices.package/extension/ChangeSet/class/fileIntoNewChangeSet_.st R System-Changes.package/ChangeSet.class/class/services/fileIntoNewChangeSet_.st M System-Changes.package/ManifestSystemChanges.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st M System-Settings.package/SettingTreeBuilder.class/instance/pragmas/systemsettings.st Log Message: ----------- 60136 18665 Rename Pragma>>#selector to Pragma>>#methodSelector https://pharo.fogbugz.com/f/cases/18665 18685 System-Changes depends on Compression https://pharo.fogbugz.com/f/cases/18685 18689 deprecate #copyLast: https://pharo.fogbugz.com/f/cases/18689 http://files.pharo.org/image/60/60136.zip

July 5, 2016

Re: [Pharo-dev] XMLWriter does not load in development in Pharo

by Henrik Johansen

I can't find the thread, but the entire protocol used to al on SmalltalkImage, which grew sort of unwieldy. Then, some time before 1.4, Pharo split off the functionality to separate classes (OSPlatform etc.), Sometime before the release of Pharo 1.4/ squeak 4.0, it was agreed that adding os / vm etc. accessors to SmalltalkImage (aka the Smalltalk global) would be a good delegation layer that allowed for writing the same code to work on both, without requiring the actual split into separate classes as Pharo did. I *think* it's all still in one place in Squeak, in Pharo, most of the original protocol now resides in the "compatability" protocol IIRC (after all, it *is* a bit nicer to write Smalltalk os/platform name). Anyways, the outcome is that in general, using Smalltalk xx yyy constructs should be what yields the widest support for the lowest amount of effort. Cheers, Henry > On 05 Jul 2016, at 1:17 , monty <monty2(a)programmer.net> wrote: > > This would be cleaner than my current fix, so I'll try it, thanks. > >> Sent: Tuesday, July 05, 2016 at 6:12 AM >> From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] XMLWriter does not load in development in Pharo >> >> If the goal is x-platform, the magic incantation that works in both Pharo and Squeak, is >> Smalltalk os platformName. >> >> Cheers, >> Henry >>> On 05 Jul 2016, at 10:41 , Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com> wrote: >>> >>> Hi, >>> >>> There was a commit in XMLWriter using `Smalltalk plateformName >>> asLowercase beginsWith: 'win'` in the initialisation of the writer >>> class. #plateformName does not exist in the Pharo image so it's >>> impossible to load the development version of XMLWriter in Pharo at the >>> moment. >>> >>> Instead I think it should use `OSPlatform current isWindows`. Or even >>> better: `OSPlatform current lineEnding`. Since I don't know if XMLWriter >>> is a Pharo project or if it's loadable in other Smalltalk I prefer to >>> send a mail instead of changing the code myself. >>> >>> -- >>> Cyril Ferlicot >>> >>> http://www.synectique.eu >>> >>> 165 Avenue Bretagne >>> Lille 59000 France >>> >> >> >

July 5, 2016

Re: [Pharo-dev] XMLWriter does not load in development in Pharo

by monty

This would be cleaner than my current fix, so I'll try it, thanks. > Sent: Tuesday, July 05, 2016 at 6:12 AM > From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] XMLWriter does not load in development in Pharo > > If the goal is x-platform, the magic incantation that works in both Pharo and Squeak, is > Smalltalk os platformName. > > Cheers, > Henry > > On 05 Jul 2016, at 10:41 , Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com> wrote: > > > > Hi, > > > > There was a commit in XMLWriter using `Smalltalk plateformName > > asLowercase beginsWith: 'win'` in the initialisation of the writer > > class. #plateformName does not exist in the Pharo image so it's > > impossible to load the development version of XMLWriter in Pharo at the > > moment. > > > > Instead I think it should use `OSPlatform current isWindows`. Or even > > better: `OSPlatform current lineEnding`. Since I don't know if XMLWriter > > is a Pharo project or if it's loadable in other Smalltalk I prefer to > > send a mail instead of changing the code myself. > > > > -- > > Cyril Ferlicot > > > > http://www.synectique.eu > > > > 165 Avenue Bretagne > > Lille 59000 France > > > >

July 5, 2016

Re: [Pharo-dev] XMLWriter does not load in development in Pharo

by monty

It's strange because "Smalltalk platformName" (the typo "plateform" is only in your post, not the source method) worked fine in my personal 5.0 image and for both stable and development 5.0 CI builds, but failed for development but not stable 3.0 and 4.0 builds. There is a new release which fixes the issue, but it is a bit more complex than using OSPlatform because XMLWriter and all XMLParser related libs target all Pharo versions back to 1.4 and recent Squeak/GemStone(gsDevKit) releases, so assuming OSPlatform is present is a non-starter. Thanks for the report. > Sent: Tuesday, July 05, 2016 at 4:41 AM > From: "Cyril Ferlicot Delbecque" <cyril.ferlicot(a)gmail.com> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, monty <monty2(a)programmer.net> > Subject: XMLWriter does not load in development in Pharo > > Hi, > > There was a commit in XMLWriter using `Smalltalk plateformName > asLowercase beginsWith: 'win'` in the initialisation of the writer > class. #plateformName does not exist in the Pharo image so it's > impossible to load the development version of XMLWriter in Pharo at the > moment. > > Instead I think it should use `OSPlatform current isWindows`. Or even > better: `OSPlatform current lineEnding`. Since I don't know if XMLWriter > is a Pharo project or if it's loadable in other Smalltalk I prefer to > send a mail instead of changing the code myself. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >

July 5, 2016

GTInspector table hides columns

by Peter UhnÃ¡k

Hi, apparently inspector is happy to hide columns if they don't fit. Why is there no vertical scrollbar? â Also (I know I brought up this in the past, but the problem still remains), why does "Description" takes up so much space even though there's no data at all? Why not cap it at the width of the heading? Thanks, Peter

July 5, 2016