- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by stepharo

So what is the conclusion? I like the idea of Esteban M to have iterator because it moves some behavior out of core classes. [[[ aCollection arithmetic sum: [...] or.... aCollection arithmetic avg. ]]]

Dec. 5, 2015

Re: [Pharo-dev] Unicode Support

by stepharo

Hi todd thanks for the link. It looks really interesting. Stef Le 5/12/15 17:35, Todd Blanchard a Ã©crit : > would suggest that the only worthwhile encoding is UTF8 - the rest are > distractions except for being able to read and convert from other > encodings to UTF8. UTF16 is a complete waste of time. > > Read http://utf8everywhere.org/ > > I have extensive Unicode chops from around 1999 to 2004 and my > experience leads me to strongly agree with the views on that site. > > > Sent from the road > > On Dec 5, 2015, at 05:08, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > >> Hi EuanM >> >> Le 4/12/15 12:42, EuanM a Ã©crit : >>> I'm currently groping my way to seeing how feature-complete our >>> Unicode support is. I am doing this to establish what still needs to >>> be done to provide full Unicode support. >> >> this is great. Thanks for pushing this. I wrote and collected some >> roadmap (analyses on different topics) >> on the pharo github project feel free to add this one there. >>> >>> This seems to me to be an area where it would be best to write it >>> once, and then have the same codebase incorporated into the Smalltalks >>> that most share a common ancestry. >>> >>> I am keen to get: equality-testing for strings; sortability for >>> strings which have ligatures and diacritic characters; and correct >>> round-tripping of data. >> Go! >> My suggestion is >> start small >> make steady progress >> write tests >> commit often :) >> >> Stef >> >> What is the french phoneBook ordering because this is the first time >> I hear about it. >>> >>> Call to action: >>> ========== >>> >>> If you have comments on these proposals - such as "but we already have >>> that facility" or "the reason we do not have these facilities is >>> because they are dog-slow" - please let me know them. >>> >>> If you would like to help out, please let me know. >>> >>> If you have Unicode experience and expertise, and would like to be, or >>> would be willing to be, in the 'council of experts' for this project, >>> please let me know. >>> >>> If you have comments or ideas on anything mentioned in this email >>> >>> In the first instance, the initiative's website will be: >>> http://smalltalk.uk.to/unicode.html >>> >>> I have created a SqueakSource.com <http://squeaksource.com> project >>> called UnicodeSupport >>> >>> I want to avoid re-inventing any facilities which already exist. >>> Except where they prevent us reaching the goals of: >>> - sortable UTF8 strings >>> - sortable UTF16 strings >>> - equivalence testing of 2 UTF8 strings >>> - equivalence testing of 2 UTF16 strings >>> - round-tripping UTF8 strings through Smalltalk >>> - roundtripping UTF16 strings through Smalltalk. >>> As I understand it, we have limited Unicode support atm. >>> >>> Current state of play >>> =============== >>> ByteString gets converted to WideString when need is automagically >>> detected. >>> >>> Is there anything else that currently exists? >>> >>> Definition of Terms >>> ============== >>> A quick definition of terms before I go any further: >>> >>> Standard terms from the Unicode standard >>> =============================== >>> a compatibility character : an additional encoding of a *normal* >>> character, for compatibility and round-trip conversion purposes. For >>> instance, a 1-byte encoding of a Latin character with a diacritic. >>> >>> Made-up terms >>> ============ >>> a convenience codepoint : a single codepoint which represents an item >>> that is also encoded as a string of codepoints. >>> >>> (I tend to use the terms compatibility character and compatibility >>> codepoint interchangably. The standard only refers to them as >>> compatibility characters. However, the standard is determined to >>> emphasise that characters are abstract and that codepoints are >>> concrete. So I think it is often more useful and productive to think >>> of compatibility or convenience codepoints). >>> >>> a composed character : a character made up of several codepoints >>> >>> Unicode encoding explained >>> ===================== >>> A convenience codepoint can therefore be thought of as a code point >>> used for a character which also has a composed form. >>> >>> The way Unicode works is that sometimes you can encode a character in >>> one byte, sometimes not. Sometimes you can encode it in two bytes, >>> sometimes not. >>> >>> You can therefore have a long stream of ASCII which is single-byte >>> Unicode. If there is an occasional Cyrillic or Greek character in the >>> stream, it would be represented either by a compatibility character or >>> by a multi-byte combination. >>> >>> Using compatibility characters can prevent proper sorting and >>> equivalence testing. >>> >>> Using "pure" Unicode, ie. "normal encodings", can cause compatibility >>> and round-tripping probelms. Although avoiding them can *also* cause >>> compatibility issues and round-tripping problems. >>> >>> Currently my thinking is: >>> >>> a Utf8String class >>> an Ordered collection, with 1 byte characters as the modal element, >>> but short arrays of wider strings where necessary >>> a Utf16String class >>> an Ordered collection, with 2 byte characters as the modal element, >>> but short arrays of wider strings >>> beginning with a 2-byte endianness indicator. >>> >>> Utf8Strings sometimes need to be sortable, and sometimes need to be >>> compatible. >>> >>> So my thinking is that Utf8String will contain convenience codepoints, >>> for round-tripping. And where there are multiple convenience >>> codepoints for a character, that it standardises on one. >>> >>> And that there is a Utf8SortableString which uses *only* normal >>> characters. >>> >>> We then need methods to convert between the two. >>> >>> aUtf8String asUtf8SortableString >>> >>> and >>> >>> aUtf8SortableString asUtf8String >>> >>> >>> Sort orders are culture and context dependent - Sweden and Germany >>> have different sort orders for the same diacritic-ed characters. Some >>> countries have one order in general usage, and another for specific >>> usages, such as phone directories (e.g. UK and France) >>> >>> Similarly for Utf16 : Utf16String and Utf16SortableString and >>> conversion methods >>> >>> A list of sorted words would be a SortedCollection, and there could be >>> pre-prepared sortBlocks for them, e.g. frPhoneBookOrder, deOrder, >>> seOrder, ukOrder, etc >>> >>> along the lines of >>> aListOfWords := SortedCollection sortBlock: deOrder >>> >>> If a word is either a Utf8SortableString, or a well-formed Utf8String, >>> then we can perform equivalence testing on them trivially. >>> >>> To make sure a Utf8String is well formed, we would need to have a way >>> of cleaning up any convenience codepoints which were valid, but which >>> were for a character which has multiple equally-valid alternative >>> convenience codepoints, and for which the string currently had the >>> "wrong" convenience codepoint. (i.e for any character with valid >>> alternative convenience codepoints, we would choose one to be in the >>> well-formed Utf8String, and we would need a method for cleaning the >>> alternative convenience codepoints out of the string, and replacing >>> them with the chosen approved convenience codepoint. >>> >>> aUtf8String cleanUtf8String >>> >>> With WideString, a lot of the issues disappear - except >>> round-tripping(although I'm sure I have seen something recently about >>> 4-byte strings that also have an additional bit. Which would make >>> some Unicode characters 5-bytes long.) >>> >>> >>> (I'm starting to zone out now - if I've overlooked anything - obvious, >>> subtle, or somewhere in between, please let me know) >>> >>> Cheers, >>> Euan >>> >>> >> >>

Dec. 5, 2015

Re: [Pharo-dev] Unicode Support

by Todd Blanchard

would suggest that the only worthwhile encoding is UTF8 - the rest are distractions except for being able to read and convert from other encodings to UTF8. UTF16 is a complete waste of time. Read http://utf8everywhere.org/ I have extensive Unicode chops from around 1999 to 2004 and my experience leads me to strongly agree with the views on that site. Sent from the road > On Dec 5, 2015, at 05:08, stepharo <stepharo(a)free.fr> wrote: > > Hi EuanM > > Le 4/12/15 12:42, EuanM a Ã©crit : >> I'm currently groping my way to seeing how feature-complete our >> Unicode support is. I am doing this to establish what still needs to >> be done to provide full Unicode support. > > this is great. Thanks for pushing this. I wrote and collected some roadmap (analyses on different topics) > on the pharo github project feel free to add this one there. >> >> This seems to me to be an area where it would be best to write it >> once, and then have the same codebase incorporated into the Smalltalks >> that most share a common ancestry. >> >> I am keen to get: equality-testing for strings; sortability for >> strings which have ligatures and diacritic characters; and correct >> round-tripping of data. > Go! > My suggestion is > start small > make steady progress > write tests > commit often :) > > Stef > > What is the french phoneBook ordering because this is the first time I hear about it. >> >> Call to action: >> ========== >> >> If you have comments on these proposals - such as "but we already have >> that facility" or "the reason we do not have these facilities is >> because they are dog-slow" - please let me know them. >> >> If you would like to help out, please let me know. >> >> If you have Unicode experience and expertise, and would like to be, or >> would be willing to be, in the 'council of experts' for this project, >> please let me know. >> >> If you have comments or ideas on anything mentioned in this email >> >> In the first instance, the initiative's website will be: >> http://smalltalk.uk.to/unicode.html >> >> I have created a SqueakSource.com project called UnicodeSupport >> >> I want to avoid re-inventing any facilities which already exist. >> Except where they prevent us reaching the goals of: >> - sortable UTF8 strings >> - sortable UTF16 strings >> - equivalence testing of 2 UTF8 strings >> - equivalence testing of 2 UTF16 strings >> - round-tripping UTF8 strings through Smalltalk >> - roundtripping UTF16 strings through Smalltalk. >> As I understand it, we have limited Unicode support atm. >> >> Current state of play >> =============== >> ByteString gets converted to WideString when need is automagically detected. >> >> Is there anything else that currently exists? >> >> Definition of Terms >> ============== >> A quick definition of terms before I go any further: >> >> Standard terms from the Unicode standard >> =============================== >> a compatibility character : an additional encoding of a *normal* >> character, for compatibility and round-trip conversion purposes. For >> instance, a 1-byte encoding of a Latin character with a diacritic. >> >> Made-up terms >> ============ >> a convenience codepoint : a single codepoint which represents an item >> that is also encoded as a string of codepoints. >> >> (I tend to use the terms compatibility character and compatibility >> codepoint interchangably. The standard only refers to them as >> compatibility characters. However, the standard is determined to >> emphasise that characters are abstract and that codepoints are >> concrete. So I think it is often more useful and productive to think >> of compatibility or convenience codepoints). >> >> a composed character : a character made up of several codepoints >> >> Unicode encoding explained >> ===================== >> A convenience codepoint can therefore be thought of as a code point >> used for a character which also has a composed form. >> >> The way Unicode works is that sometimes you can encode a character in >> one byte, sometimes not. Sometimes you can encode it in two bytes, >> sometimes not. >> >> You can therefore have a long stream of ASCII which is single-byte >> Unicode. If there is an occasional Cyrillic or Greek character in the >> stream, it would be represented either by a compatibility character or >> by a multi-byte combination. >> >> Using compatibility characters can prevent proper sorting and >> equivalence testing. >> >> Using "pure" Unicode, ie. "normal encodings", can cause compatibility >> and round-tripping probelms. Although avoiding them can *also* cause >> compatibility issues and round-tripping problems. >> >> Currently my thinking is: >> >> a Utf8String class >> an Ordered collection, with 1 byte characters as the modal element, >> but short arrays of wider strings where necessary >> a Utf16String class >> an Ordered collection, with 2 byte characters as the modal element, >> but short arrays of wider strings >> beginning with a 2-byte endianness indicator. >> >> Utf8Strings sometimes need to be sortable, and sometimes need to be compatible. >> >> So my thinking is that Utf8String will contain convenience codepoints, >> for round-tripping. And where there are multiple convenience >> codepoints for a character, that it standardises on one. >> >> And that there is a Utf8SortableString which uses *only* normal characters. >> >> We then need methods to convert between the two. >> >> aUtf8String asUtf8SortableString >> >> and >> >> aUtf8SortableString asUtf8String >> >> >> Sort orders are culture and context dependent - Sweden and Germany >> have different sort orders for the same diacritic-ed characters. Some >> countries have one order in general usage, and another for specific >> usages, such as phone directories (e.g. UK and France) >> >> Similarly for Utf16 : Utf16String and Utf16SortableString and >> conversion methods >> >> A list of sorted words would be a SortedCollection, and there could be >> pre-prepared sortBlocks for them, e.g. frPhoneBookOrder, deOrder, >> seOrder, ukOrder, etc >> >> along the lines of >> aListOfWords := SortedCollection sortBlock: deOrder >> >> If a word is either a Utf8SortableString, or a well-formed Utf8String, >> then we can perform equivalence testing on them trivially. >> >> To make sure a Utf8String is well formed, we would need to have a way >> of cleaning up any convenience codepoints which were valid, but which >> were for a character which has multiple equally-valid alternative >> convenience codepoints, and for which the string currently had the >> "wrong" convenience codepoint. (i.e for any character with valid >> alternative convenience codepoints, we would choose one to be in the >> well-formed Utf8String, and we would need a method for cleaning the >> alternative convenience codepoints out of the string, and replacing >> them with the chosen approved convenience codepoint. >> >> aUtf8String cleanUtf8String >> >> With WideString, a lot of the issues disappear - except >> round-tripping(although I'm sure I have seen something recently about >> 4-byte strings that also have an additional bit. Which would make >> some Unicode characters 5-bytes long.) >> >> >> (I'm starting to zone out now - if I've overlooked anything - obvious, >> subtle, or somewhere in between, please let me know) >> >> Cheers, >> Euan > >

Dec. 5, 2015

Re: [Pharo-dev] Unicode Support

by Todd Blanchard

Sent from the road > On Dec 5, 2015, at 05:08, stepharo <stepharo(a)free.fr> wrote: > > Hi EuanM > > Le 4/12/15 12:42, EuanM a Ã©crit : >> I'm currently groping my way to seeing how feature-complete our >> Unicode support is. I am doing this to establish what still needs to >> be done to provide full Unicode support. > > this is great. Thanks for pushing this. I wrote and collected some roadmap (analyses on different topics) > on the pharo github project feel free to add this one there. >> >> This seems to me to be an area where it would be best to write it >> once, and then have the same codebase incorporated into the Smalltalks >> that most share a common ancestry. >> >> I am keen to get: equality-testing for strings; sortability for >> strings which have ligatures and diacritic characters; and correct >> round-tripping of data. > Go! > My suggestion is > start small > make steady progress > write tests > commit often :) > > Stef > > What is the french phoneBook ordering because this is the first time I hear about it. >> >> Call to action: >> ========== >> >> If you have comments on these proposals - such as "but we already have >> that facility" or "the reason we do not have these facilities is >> because they are dog-slow" - please let me know them. >> >> If you would like to help out, please let me know. >> >> If you have Unicode experience and expertise, and would like to be, or >> would be willing to be, in the 'council of experts' for this project, >> please let me know. >> >> If you have comments or ideas on anything mentioned in this email >> >> In the first instance, the initiative's website will be: >> http://smalltalk.uk.to/unicode.html >> >> I have created a SqueakSource.com project called UnicodeSupport >> >> I want to avoid re-inventing any facilities which already exist. >> Except where they prevent us reaching the goals of: >> - sortable UTF8 strings >> - sortable UTF16 strings >> - equivalence testing of 2 UTF8 strings >> - equivalence testing of 2 UTF16 strings >> - round-tripping UTF8 strings through Smalltalk >> - roundtripping UTF16 strings through Smalltalk. >> As I understand it, we have limited Unicode support atm. >> >> Current state of play >> =============== >> ByteString gets converted to WideString when need is automagically detected. >> >> Is there anything else that currently exists? >> >> Definition of Terms >> ============== >> A quick definition of terms before I go any further: >> >> Standard terms from the Unicode standard >> =============================== >> a compatibility character : an additional encoding of a *normal* >> character, for compatibility and round-trip conversion purposes. For >> instance, a 1-byte encoding of a Latin character with a diacritic. >> >> Made-up terms >> ============ >> a convenience codepoint : a single codepoint which represents an item >> that is also encoded as a string of codepoints. >> >> (I tend to use the terms compatibility character and compatibility >> codepoint interchangably. The standard only refers to them as >> compatibility characters. However, the standard is determined to >> emphasise that characters are abstract and that codepoints are >> concrete. So I think it is often more useful and productive to think >> of compatibility or convenience codepoints). >> >> a composed character : a character made up of several codepoints >> >> Unicode encoding explained >> ===================== >> A convenience codepoint can therefore be thought of as a code point >> used for a character which also has a composed form. >> >> The way Unicode works is that sometimes you can encode a character in >> one byte, sometimes not. Sometimes you can encode it in two bytes, >> sometimes not. >> >> You can therefore have a long stream of ASCII which is single-byte >> Unicode. If there is an occasional Cyrillic or Greek character in the >> stream, it would be represented either by a compatibility character or >> by a multi-byte combination. >> >> Using compatibility characters can prevent proper sorting and >> equivalence testing. >> >> Using "pure" Unicode, ie. "normal encodings", can cause compatibility >> and round-tripping probelms. Although avoiding them can *also* cause >> compatibility issues and round-tripping problems. >> >> Currently my thinking is: >> >> a Utf8String class >> an Ordered collection, with 1 byte characters as the modal element, >> but short arrays of wider strings where necessary >> a Utf16String class >> an Ordered collection, with 2 byte characters as the modal element, >> but short arrays of wider strings >> beginning with a 2-byte endianness indicator. >> >> Utf8Strings sometimes need to be sortable, and sometimes need to be compatible. >> >> So my thinking is that Utf8String will contain convenience codepoints, >> for round-tripping. And where there are multiple convenience >> codepoints for a character, that it standardises on one. >> >> And that there is a Utf8SortableString which uses *only* normal characters. >> >> We then need methods to convert between the two. >> >> aUtf8String asUtf8SortableString >> >> and >> >> aUtf8SortableString asUtf8String >> >> >> Sort orders are culture and context dependent - Sweden and Germany >> have different sort orders for the same diacritic-ed characters. Some >> countries have one order in general usage, and another for specific >> usages, such as phone directories (e.g. UK and France) >> >> Similarly for Utf16 : Utf16String and Utf16SortableString and >> conversion methods >> >> A list of sorted words would be a SortedCollection, and there could be >> pre-prepared sortBlocks for them, e.g. frPhoneBookOrder, deOrder, >> seOrder, ukOrder, etc >> >> along the lines of >> aListOfWords := SortedCollection sortBlock: deOrder >> >> If a word is either a Utf8SortableString, or a well-formed Utf8String, >> then we can perform equivalence testing on them trivially. >> >> To make sure a Utf8String is well formed, we would need to have a way >> of cleaning up any convenience codepoints which were valid, but which >> were for a character which has multiple equally-valid alternative >> convenience codepoints, and for which the string currently had the >> "wrong" convenience codepoint. (i.e for any character with valid >> alternative convenience codepoints, we would choose one to be in the >> well-formed Utf8String, and we would need a method for cleaning the >> alternative convenience codepoints out of the string, and replacing >> them with the chosen approved convenience codepoint. >> >> aUtf8String cleanUtf8String >> >> With WideString, a lot of the issues disappear - except >> round-tripping(although I'm sure I have seen something recently about >> 4-byte strings that also have an additional bit. Which would make >> some Unicode characters 5-bytes long.) >> >> >> (I'm starting to zone out now - if I've overlooked anything - obvious, >> subtle, or somewhere in between, please let me know) >> >> Cheers, >> Euan > >

Dec. 5, 2015

Re: [Pharo-dev] Cannot upload file on Smalltalkhub

by Juraj Kubelka

Thanks a lot! Juraj -- Juraj Kubelka 5. 12. 2015 v 7:48, Marcus Denker <marcus.denker(a)inria.fr>: > Done, copied both to rubric repo and then the config to the inbox in addition. > >> On 04 Dec 2015, at 19:14, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >> >> Hi, >> >> For some reasons I cannot upload mcz files on Smalltalkhub: 500 Internal Server Error text/plain;charset=utf-8 30B >> >> Am I only one? I need to upload following files into Pharo/Rubric: >> >> >> <Rubric-JurajKubelka.310.mcz><ConfigurationOfRubric-JurajKubelka.97.mcz> >> >> Thanks for any help, >> Juraj > >

Dec. 5, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Max Leske

> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Can you try with the latest version that does not use LPC if it works? Works perfectly!

Dec. 5, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Max Leske

> On 05 Dec 2015, at 14:07, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Sat, Dec 5, 2015 at 8:58 AM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > > On Sat, Dec 5, 2015 at 7:33 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > Good stuff Mariano! I think a similar approach will work for Seaside 2.8. > > > Great. > > - I think you might want to override #handleException: and inject the process variable there. Then it doesnât matter from where the debugger is being opened and you donât have to mess with the exception handling logic (which inevitably leads to trouble in my experience). > > Good idea. The reason I was hooking there is because I was setting in the process local variable once I know I was already at the UI Manager process and no the Zinc Server one that was processing the request. > However...let me explain... Whenever you evaluate something from the debugger, inspector, etc...all that is being run with UI Manager process. While the stack you debugging was actually created at another process (the Zinc Server one that was processing the request). If we store in PLC (processor local variables) when we are in the Zinc process, then the debugger does not see the values at all (since it is in UIManager). We may be able to fix this, but we will need to hook in every possible "evaluation" done from debugger: inspect, do it, print it, etc etc etc. The only reason it make sense to store the values in PLC of the Zinc process rather than UIManager (and make all necessary hooks in inspect, print, etc) is because that would allow us to debug multiple exceptions at the same time. Right now, since values are stored in PLC of UIManager, those are shared for all debuggers. Meaning...you allow only ONE debugger. The last debugger will set new values and the older debuggers will now get the "new values". You can verify this yourself by opening 2 debuggers from my test case. > > Anyway.... if we are already going to support 1 one debugger at a time (it's more than enough for my needs), it make no sense to use PLC from UIManager. In fact, the values could be stored ANYWHERE. The only condition is to be able to reach them in each WADynamicVariable subclass >> defaultValue. > > In my last commit you can see this new approach. For this experiment I store things in Smalltalk globals but next I will: > > 1) Use a class side variable in WAPharoDebuggererErrorHandler > 2) Automatically store all subclasses of WADynamicValue with convetion..say: > That might be the better approach. More transparent too. > > > I just committed that. > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >> mmmmm are you sure this works? (in any case, we will not go that path anymore but I am curious if that did work for you) > by "works" I mean if you tested with WACurrentRequestDebuggingTest and followed the steps in its comments (the identityHash comparison to transcript). Actually, I did test it before I replied to your e-mail. But now it seems I must have evaluated the wrong piece of code or something. If you think about it of course it makes sense: any #DoIt has a separate stack, so the exception handling mechanism will not find those handlers.

Dec. 5, 2015

Re: [Pharo-dev] SessionManager (aka new startup / shutdown list manager) needs testers

by Christophe Demarey

----- Mail original ----- > De: "Nicolai Hess" <nicolaihess(a)gmail.com> > Ã: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > EnvoyÃ©: Vendredi 4 DÃ©cembre 2015 22:05:26 > Objet: Re: [Pharo-dev] SessionManager (aka new startup / shutdown list > manager) needs testers > Looks good. What are the main critical startup/shutdown users( classes) that > should be tested? Classes using startup or/and shutdown are #SmallInteger #Delay atPriority #ProcessorScheduler #InputEventFetche #InputEventFetcher #OSPlatfor #Stdio #LanguageEnvironment #ShortIntegerArray #DiskStore #SmalltalkImage #WeakFinalizationList #Clipboard #MCMethodDefinition #Symbol #Locale #MultiByteFileStream #WeakArray #FileStream #FileLocator #BasicCommandLineHandler #NonInteractiveTranscript #ASTCache #OSEnvironment #EndianDetector #InternetConfiguration #ZnServer #MCGitHubRepository #ZnLogEvent #DisplayScreen #InputEventSensor #Cursor #Form #StrikeFont #Color #FreeTypeCache #LogicalFont #FT2Handle #FreeTypeSettings #WorldMorph #CPUWatcher #NOCCompletionTable #Nautilus #PharoCommonTools #GTPlayBook Also sensitive code could be the one using the session (Smalltalk session) to check if they need to free or reset some resources. Thanks to have a look at it, Christophe > I did some tests with AthensSceneView (uses NB and calls Smalltalk session > for reinit external resources) and Roassal. > I got one image startup failure, but I couldn't reproduce it yet. Maybe I did > image save and image save and quit, too quick.

Dec. 5, 2015

[pharo-project/pharo-core]

by GitHub

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

Dec. 5, 2015

[pharo-project/pharo-core] 88cab8: 50487

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 88cab84fb6133980ee3626403fc4051134e52766 https://github.com/pharo-project/pharo-core/commit/88cab84fb6133980ee362640… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-05 (Sat, 05 Dec 2015) Changed paths: M Morphic-Core.package/Morph.class/instance/events-processing/handlesMouseMove_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50486.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50487.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50486.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50487.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Shout.package/SHRBTextStyler.class/class/configuration/enableAstHighlightSetting_.st R Shout.package/SHRBTextStyler.class/class/configuration/useAstColoring.st R Shout.package/SHRBTextStyler.class/class/configuration/useAstColoring_.st M Shout.package/SHTextStylerST80.class/class/initialization/initialize.st R Shout.package/SHTextStylerST80.class/class/initialization/unload.st Log Message: ----------- 50487 17196 Remove check for event handler in #handlesMouseMove: https://pharo.fogbugz.com/f/cases/17196 17191 remove option #useAstColoring https://pharo.fogbugz.com/f/cases/17191 17079 no syntax highlighting in TimeProfilers code pane https://pharo.fogbugz.com/f/cases/17079 http://files.pharo.org/image/50/50487.zip

Dec. 5, 2015