December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Crypto plugins for ubuntu 32-bits

by David T. Lewis

On Fri, Dec 04, 2015 at 09:57:02PM -0500, Robert Withers wrote: > I loaded the CryptographyPlugins package, from the Cryptography > repository into a VMMaker image, and generated the crypto plugins > externally. Although I have not measured it rigorously, there is a > noticeable performance improvement with SqueakElib tests. > > Untar these Ubuntu 32-bit crypto plugins into /usr/local/lib/squeak/5.0... > > https://www.dropbox.com/s/v502zudwsbtr243/CryptoPlugins.ubuntu32.12.4.15.tg… > > Let me know any issues. > > Regards, > Robert Yikes, it seems that we have had this issue open for nearly 10 years now: http://bugs.squeak.org/view.php?id=5228 "0005228: Include Cryptographic Primitives in Base VM - DESPlugin" Robert, I think you are on the vm-dev list, may I ask some follow up questions there? Dave

Dec. 5, 2015

Re: [Pharo-dev] Help needed: old issues issue tracker entries

by Marcus Denker

> On 30 Nov 2015, at 13:21, marcus.denker(a)inria.fr wrote: > > Hi, > > The issue tracker has 658 open issues. This number is more or less constant. > down to 642! (of course we closed more than that, we are at more than 6 per day closed, but the thing is that new ones get open, too) With >600 issues open, if someone adds a comment in the sense of âthis can be closedâ, can you send me (or the List) a mail? Or put the issue on âfixedâ ? The problem is that with >600 issues, even an issue that is clearly commented as fixed has a very low chance of someone reading the note and closing the entry within any reasonable time frame if we rely on someone stumbling on it by chance... Marcus

Dec. 5, 2015

Re: [Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

by Eliot Miranda

Hi Andrei, > On Dec 4, 2015, at 11:29 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > >> On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> 2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> Hi Nicolai, >>> >>>> On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> GTDummyExamples class >>>> d: anInteger >>>> <gtExample> >>>> <label: 'Dummy #d:, depends #c:'> >>>> <description: 'should raise an exception as the argument is not anInteger'> >>>> <depends: #c:> >>>> <raises: Literal constant expected -> MessageNotUnderstood> >>>> >>>> ^ 1 + anInteger >>>> >>>> The old Parser complains about the class name "MessageNotUnderstood" used as a pragma >>>> argument without being a string or symbol >>>> >>>> Opal does not complain >>>> >>>> Is Opals behavior intended ? >>> >>> IMO no. The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g. >>> >>> addressField >>> <primitive: 'primAddressField' module: 'IA32ABI' error: errorCode> >>> ^self primitiveFailed >>> >>> instead of >>> >>> addressField >>> <primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'> >>> ^self primitiveFailed >>> >>> >>> The issues are class reference, class redefinition, class removal etc. I guess we could extend the pragma syntax to allow class references but there's a lot of impact. I would prefer if we keep things restricted. There's nothing to stop one using a symbol and mapping it to a class name, e.g. >>> >>> >>> GTDummyExamples class >>> d: anInteger >>> <gtExample> >>> <label: 'Dummy #d:, depends #c:'> >>> <description: 'should raise an exception as the argument is not anInteger'> >>> <depends: #c:> >>> <raises: #MessageNotUnderstood> >>> >>> ^ 1 + anInteger >> >> >> Thanks eliot >> >> Yes, we have this code too, I think, using the global var instead of a symbol happened by accident. >> >> @andrei (and stefan?) can you check the GTDummyExamples methods >> and replace classes with symbol names. >> >> After this is removed I will change the parser to notify about this. > > I updated the pragmas to use symbols. They should be instances of Message, and the Message should hold onto the selector symbol and the argument. There should also be a Pragma class with an api that supports access. I'll gather up the relevant Squeak code (including tests) as a guide. Ok? > > Cheers, > Andrei > >> >> >>> >>> Also, I *hate* this style of pragma. Why not >>> >>> GTDummyExamples class >>> d: anInteger >>> <gtExampleLabel: 'Dummy #d:, depends #c:' >>> description: 'should raise an exception as the argument is not anInteger' >>> depends: #c: >>> raises: #MessageNotUnderstood> >>> >>> ^ 1 + anInteger >>> >>> ? >> >> no idea. >> >> >>> >>> That's how the system is designed to be used. Then the message can be implemented by a builder which performs the selector from a visitor. >>> >>>> From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770 >>>> >>>> Cascading message sends to super. >>>> >>>> Compiler refuses to compile >>>> super >>>> initialize; >>>> setListProperties >>>> >>>> >>>> It looks like Opal would compile this to >>>> >>>> super initialize. >>>> super setListProperties. >>>> >>>> Intended ? Do we want to keep it? >>>> >>>> NBNativeCodeGen >>>> parseOptions: optionsArray >>>> uses association symbol -> block instead of block -> block >>>> for caseOf arguments. >>>> The old parser does not accept this. >>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >

Dec. 5, 2015

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