Squeak-dev December 2015

squeak-dev@lists.squeakfoundation.org

60 participants
161 discussions

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))
by H. Hirzel 09 Dec '15

09 Dec '15

It seems that people at Twitter just did this for Ruby -- reimplementation from scratch with an API oriented towards Ruby users. A summary http://wiki.squeak.org/squeak/6263 Of course it depends on what you expect to achieve. This thread starts with aiming at getting German, French and Spanish sorting done. Plus some other similar cases. The algorithms are table driven and the tables are read into the Smalltalk image as is. As of now the Unicode Character Database is in the Squeak/Pharo image http://wiki.squeak.org/squeak/6244 Getting the sorting done does not seem to be extraordinary hard. However making use of the Smalltalk ICU wrapper is surely an option. --Hannes On 12/9/15, Todd Blanchard <tblanchard(a)mac.com> wrote: > They are practically the same thing. > > ICU was developed by Taligent which was a joint venture between Apple and > IBM. Makes sense that NSString and ICU's UnicodeString are pretty close in > implementation. ICU was also ported to Java for Sun by IBM. The point is - > this is a very elaborate chunk of code with far reach. If ICU is wrong on > some point - it is universally wrong and thus likely to be taken as "right" > as it is at least consistent. I think re-implementing it is folly TBH. > Just use it. > >> On Dec 8, 2015, at 15:52, EuanM <euanmee(a)gmail.com> wrote: >> >> Equally old are the NextStep Object C functions which are now embodied >> within MacOS X. >> > > >

1 0

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))
by H. Hirzel 09 Dec '15

09 Dec '15

On 12/8/15, Todd Blanchard <tblanchard(a)mac.com> wrote: > I just want to second Dale's endorsement of the ICU library. It has been > around a long time (originally developed by Taligent) and it provides the > base unicode capabilities for an awful lot of software. > > I think it would make more sense to bring icu into Smalltalk as a > NativeBoost library than to spend resources reimplementing and maintaining > it. > > -Todd Blanchard ICU already seems to be available for Smalltalk accessed through wrappers http://wiki.squeak.org/squeak/6234 --Hannes >> On Dec 8, 2015, at 11:20, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> >> wrote: >> >> On 12/07/2015 11:31 PM, H. Hirzel wrote: >>> Dale >>> >>> Thank you for your answer with links to the ICU library and the notes >>> about classes in Gemstone. Noteworthy that you have a class Utf8 as a >>> subclass of ByteArray. >>> >>> I understand that Gemstone uses the ICU library and thus does not >>> implement the algorithms in Smalltalk. >>> >>> I am currently looking into what the ICU library provides. > >

1 0

Fwd: [Pharo-dev] Unicode Support
by EuanM 09 Dec '15

09 Dec '15

"Well. I do not agree with this. I agree with the quote. Can you explain a bit more about what you mean by abstract character and concept?" --Guillermo The problem with the quote is, that *while true*, it *does not disambiguate* between: either compatibility character and abstract character; or character as composable component of an abstract character and character as the entire embodiment of an abstract character; Abstract character is the key concept of Unicode. Differentiation between abstract character and codepoints is the key differentiator of the Unicode approach and most previous approaches to character encoding, e,g, ASCII, EBCDIC, ISO Latin 1, etc Please see my previous posts which use the example of Angstrom, Capital A with circle (or whatever the canonical name is) and the composed sequence of "Capital A" and "circle above a letter" for a fuller explanation of the concept of "abstract character". On 9 December 2015 at 09:35, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> On 8 dic 2015, at 10:07 p.m., EuanM <euanmee(a)gmail.com> wrote: >> >> "No. a codepoint is the numerical value assigned to a character. An >> "encoded character" is the way a codepoint is represented in bytes >> using a given encoding." >> >> No. >> >> A codepoint may represent a component part of an abstract character, >> or may represent an abstract character, or it may do both (but not >> always at the same time). >> >> Codepoints represent a single encoding of a single concept. >> >> Sometimes that concept represents a whole abstract character. >> Sometimes it represent part of an abstract character. > > Well. I do not agree with this. I agree with the quote. > > Can you explain a bit more about what you mean by abstract character and concept? > >> >> This is the key difference between Unicode and most character encodings. >> >> A codepoint does not always represent a whole character. >> >> On 7 December 2015 at 13:06, Henrik Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 07 Dec 2015, at 1:05 , EuanM <euanmee(a)gmail.com> wrote: >>> >>> Hi Henry, >>> >>> To be honest, at some point I'm going to long for the for the much >>> more succinct semantics of healthcare systems and sports scoring and >>> administration systems again. :-) >>> >>> codepoints are any of *either* >>> - the representation of a component of an abstract character, *or* >>> eg. "A" #(0041) as a component of >>> - the sole representation of the whole of an abstract character *or* of >>> - a representation of an abstract character provided for backwards >>> compatibility which is more properly represented by a series of >>> codepoints representing a composed character >>> >>> e.g. >>> >>> The "A" #(0041) as a codepoint can be: >>> the sole representation of the whole of an abstract character "A" #(0041) >>> >>> The representation of a component of the composed (i.e. preferred) >>> version of the abstract character Å #(0041 030a) >>> >>> Å (#00C5) represents one valid compatibility form of the abstract >>> character Å which is most properly represented by #(0041 030a). >>> >>> Å (#212b) also represents one valid compatibility form of the abstract >>> character Å which is most properly represented by #(0041 030a). >>> >>> With any luck, this satisfies both our semantic understandings of the >>> concept of "codepoint" >>> >>> Would you agree with that? >>> >>> In Unicode, codepoints are *NOT* an abstract numerical representation >>> of a text character. >>> >>> At least not as we generally understand the term "text character" from >>> our experience of non-Unicode character mappings. >>> >>> >>> I agree, they are numerical representations of what Unicode refers to as >>> characters. >>> >>> >>> codepoints represent "*encoded characters*" >>> >>> >>> No. a codepoint is the numerical value assigned to a character. An "encoded >>> character" is the way a codepoint is represented in bytes using a given >>> encoding. >>> >>> and "a *text element* ... >>> is represented by a sequence of one or more codepoints". (And the >>> term "text element" is deliberately left undefined in the Unicode >>> standard) >>> >>> Individual codepoints are very often *not* the encoded form of an >>> abstract character that we are interested in. Unless we are >>> communicating to or from another system (Which in some cases is the >>> Smalltalk ByteString class) >>> >>> >>> >>> >>> i.e. in other words >>> >>> *Some* individual codepoints *may* be a representation of a specific >>> *abstract character*, but only in special cases. >>> >>> The general case in Unicode is that Unicode defines (a) >>> representation(s) of a Unicode *abstract character*. >>> >>> The Unicode standard representation of an abstract character is a >>> composed sequence of codepoints, where in some cases that sequence is >>> as short as 1 codepoint. >>> >>> In other cases, Unicode has a compatibility alias of a single >>> codepoint which is *also* a representation of an abstract character >>> >>> There are some cases where an abstract character can be represented by >>> more than one single-codepoint compatibility codepoint. >>> >>> Cheers, >>> Euan >>> >>> >>> I agree you have a good grasp of the distinction between an abstract >>> character (characters and character sequences which should be treated >>> equivalent wrt, equality / sorting / display, etc.) and a character (which >>> each have a code point assigned). >>> That is besides the point both Sven and I tried to get through, which is the >>> difference between a code point and the encoded form(s) of said code point. >>> When you write: >>> "and therefore encodable in UTF-8 as compatibility codepoint e9 hex >>> and as the composed character #(0065 00b4) (all in hex) and as the >>> same composed character as both >>> #(feff 0065 00b4) and #(ffef 0065 00b4) when endianness markers are >>> included" >>> >>> I's quite clear you confuse the two. 0xFEFF is the codepoint of the >>> character used as bom. >>> When you state that it can be written ffef (I assume you meant FFFE), you >>> are again confusing the code point and its encoded value (an encoded value >>> which only occurs in UTF16/32, no less). >>> >>> When this distinction is clear, it might be easier to see that value in that >>> Strings are kept as Unicode code points arrays, and converted to encoded >>> forms when entering/exiting the system. >>> >>> Cheers, >>> Henry >>> >> > >

1 0

Re: [Pharo-dev] Unicode Support
by EuanM 09 Dec '15

09 Dec '15

"To encode Unicode for external representation as bytes, we use UTF-8 like the rest of the modern world. So far, so good. Why all the confusion ?" The confusion arises because simply providing *a* valid UTF-8 encoding of does not ensure sortability, nor equivalence testability. It might provide sortable strings. It might not. It might provide a string that can be compared to another string successfully. It might not. So being able to perform valid UTF-8 encoding is *necessary*, but *not sufficient*. i.e. the confusion arises because UTF-8 can provide for several competing, non-sortable encodings of even a single character. This means that *valid* UTF-8 cannot be relied upon to provide these facilities *unless* all the UTF-8 strings can be relied upon to have been encoded to UTF-8 by the same specification of process. i.e. *unless* it has gone through a process of being converted by *a specific* valid method of encoding to UTF-8. Understanding the concept of abstract character is, imo key to understanding the differences between the various valid UTF-8 forms of a given abstract character. Cheers, Euan On 9 December 2015 at 10:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 09 Dec 2015, at 10:35, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> >>> On 8 dic 2015, at 10:07 p.m., EuanM <euanmee(a)gmail.com> wrote: >>> >>> "No. a codepoint is the numerical value assigned to a character. An >>> "encoded character" is the way a codepoint is represented in bytes >>> using a given encoding." >>> >>> No. >>> >>> A codepoint may represent a component part of an abstract character, >>> or may represent an abstract character, or it may do both (but not >>> always at the same time). >>> >>> Codepoints represent a single encoding of a single concept. >>> >>> Sometimes that concept represents a whole abstract character. >>> Sometimes it represent part of an abstract character. >> >> Well. I do not agree with this. I agree with the quote. >> >> Can you explain a bit more about what you mean by abstract character and concept? > > I am pretty sure that this whole discussion does more harm than good for most people's understanding of Unicode. > > It is best and (mostly) correct to think of a Unicode string as a sequence of Unicode characters, each defined/identified by a code point (out of 10.000s covering all languages). That is what we have today in Pharo (with the distinction between ByteString and WideString as mostly invisible implementation details). > > To encode Unicode for external representation as bytes, we use UTF-8 like the rest of the modern world. > > So far, so good. > > Why all the confusion ? Because the world is a complex place and the Unicode standard tries to cover all possible things. Citing all these exceptions and special cases will make people crazy and give up. I am sure that most stopped reading this thread. > > Why then is there confusion about the seemingly simple concept of a character ? Because Unicode allows different ways to say the same thing. The simplest example in a common language is (the French letter é) is > > LATIN SMALL LETTER E WITH ACUTE [U+00E9] > > which can also be written as > > LATIN SMALL LETTER E [U+0065] followed by COMBINING ACUTE ACCENT [U+0301] > > The former being a composed normal form, the latter a decomposed normal form. (And yes, it is even much more complicated than that, it goes on for 1000s of pages). > > In the above example, the concept of character/string is indeed fuzzy. > > HTH, > > Sven > >

1 0

Re: [Pharo-users] evolutions of squeakelib & crypto (Reed Solomon)
by Robert Withers 09 Dec '15

09 Dec '15

I just realized that the squeak version uses ReferenceStream while the Pharo version uses Fuel, so the binary serializations are different and they won't speak to each other. Any chance that Fuel is ported to Squeak? Regards, Robert On 12/04/2015 06:11 AM, Robert Withers wrote: > I am unable to import these files into SqueakSource, so it may be best > done from inside Pharo with Monticello. Here are working Crypto and > SqueakElib in Pharo, prior to SecureSession refactoring and Reed > Solomon. I include the correct version of LayeredProtocol. > > Regards, > Robert > > > On 12/04/2015 05:47 AM, Robert Withers wrote: >> Best Regards >> >> http://www.squeaksource.com/Cryptography.html >> http://www.squeaksource.com/squeakelib.html >> >> >> On 12/04/2015 05:44 AM, Robert Withers wrote: >>> After my password reset on squeaksource, I committed to both >>> Cryptography and SqueakElib, project links below. >>> >>> In the case of Cryptography, I had a version ported to Pharo ... I >>> will organize Pharo ports of both after Reed Solomon is stable, and >>> announce them to the Pharo list. This way both environments can be >>> supported through this one repository. >>> >>> Robert >>> >>> On 12/04/2015 04:35 AM, Stephan Eggermont wrote: >>>> On 03-12-15 23:06, Robert Withers wrote: >>>>> Are any of these used by both squeak and Pharo? That would be the >>>>> right >>>>> move I think. I will ask about getting my password reset for >>>>> squeaksource, since that is where the old code resides. >>>> >>>> All of them. Mostly timing of project start/high activity and who are >>>> maintaining it decided on platforms. There was a time when >>>> squeaksource was not so stable and then many projects migrated, and >>>> I currently hear least about stability issues from ss3, but the >>>> load on smalltalkhub is much higher, I assume, as that is used for >>>> the pharo ci. >>>> >>>> In the not so far future Pharo is likely to move to a git based >>>> infrastructure, using libgit2. Early adopters are already using it. >>>> I haven't heard the squeak ideas about that. >>>> >>>> Stephan >>>> >>>> >>>> >>> >> >

8 12

Re: [Pharo-users] evolutions of squeakelib & crypto (Reed Solomon)
by Robert Withers 09 Dec '15

09 Dec '15

Now I think you are right on with your observation. Additionally, the number of dialects could increase further with Fuel serialization, just port SecureSession and bits. Alright, I came up with a name and it may border on the egregious ... presenting ... "Maelstrom" A new distributed metric will be established in Maelstrom to measure intra- & inter-vat activity: "Sanguinity". Robert PS. thanks for pointing out Fuel support for older squeaks. On 12/04/2015 10:25 AM, Sven Van Caekenberghe wrote: > Another suggestion: if you intend to make something cross dialect and hope to get traction, I would not use a project name which contains one dialect, but something more general like Cryptography, or some cool project name, like Seaside, Fuel, ... > >> On 04 Dec 2015, at 15:43, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> I use squeak 5.0 and would want the Fuel support to customize for wire serializations and substitutions, such that Squeak and Pharo could talk to each other, and all other Fuel environments. The Fuel changes I made are in the Pharo port of SqueakElib in the SqueakElib-CapTP-Serialization category and consist of a Decoder, Materializer and a Materialization. >> >> Robert >> >> On 12/04/2015 09:35 AM, Esteban Lorenzano wrote: >>> which squeak version? >>> of what? >>> >>>> On 04 Dec 2015, at 12:15, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>>> >>>> I just realized that the squeak version uses ReferenceStream while the Pharo version uses Fuel, so the binary serializations are different and they won't speak to each other. Any chance that Fuel is ported to Squeak? >>>> >>>> Regards, >>>> Robert >>>> >>>> On 12/04/2015 06:11 AM, Robert Withers wrote: >>>>> I am unable to import these files into SqueakSource, so it may be best done from inside Pharo with Monticello. Here are working Crypto and SqueakElib in Pharo, prior to SecureSession refactoring and Reed Solomon. I include the correct version of LayeredProtocol. >>>>> >>>>> Regards, >>>>> Robert >>>>> >>>>> >>>>> On 12/04/2015 05:47 AM, Robert Withers wrote: >>>>>> Best Regards >>>>>> >>>>>> http://www.squeaksource.com/Cryptography.html >>>>>> http://www.squeaksource.com/squeakelib.html >>>>>> >>>>>> >>>>>> On 12/04/2015 05:44 AM, Robert Withers wrote: >>>>>>> After my password reset on squeaksource, I committed to both Cryptography and SqueakElib, project links below. >>>>>>> >>>>>>> In the case of Cryptography, I had a version ported to Pharo ... I will organize Pharo ports of both after Reed Solomon is stable, and announce them to the Pharo list. This way both environments can be supported through this one repository. >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> On 12/04/2015 04:35 AM, Stephan Eggermont wrote: >>>>>>>> On 03-12-15 23:06, Robert Withers wrote: >>>>>>>>> Are any of these used by both squeak and Pharo? That would be the right >>>>>>>>> move I think. I will ask about getting my password reset for >>>>>>>>> squeaksource, since that is where the old code resides. >>>>>>>> All of them. Mostly timing of project start/high activity and who are >>>>>>>> maintaining it decided on platforms. There was a time when squeaksource was not so stable and then many projects migrated, and I currently hear least about stability issues from ss3, but the load on smalltalkhub is much higher, I assume, as that is used for the pharo ci. >>>>>>>> >>>>>>>> In the not so far future Pharo is likely to move to a git based infrastructure, using libgit2. Early adopters are already using it. >>>>>>>> I haven't heard the squeak ideas about that. >>>>>>>> >>>>>>>> Stephan >>>>>>>> >>>>>>>> >>>>>>>> >

6 13

The Trunk: Tools-pre.659.mcz
by commits＠source.squeak.org 09 Dec '15

09 Dec '15

David T. Lewis uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-pre.659.mcz ==================== Summary ==================== Name: Tools-pre.659 Author: pre Time: 8 December 2015, 7:16:41.034 pm UUID: a7cb3cba-074b-46a6-8a83-fada58007b25 Ancestors: Tools-eem.658 This adds balloon help texts to the message list of the standard browser to explain the symbols shown in front of message names. =============== Diff against Tools-eem.658 =============== Item was changed: ----- Method: Browser>>messageHelpAt: (in category 'message list') ----- messageHelpAt: anIndex "Show the first n lines of the sources code of the selected message." + | source formatted | - | source formatted lineCount | Preferences balloonHelpInMessageLists ifFalse: [^ nil]. self messageList size < anIndex ifTrue: [^ nil]. source := (self selectedClassOrMetaClass >> (self messageList at: anIndex)) getSource. + source lineCount > 5 ifTrue: [ + | sourceLines | + sourceLines := (source asString lines copyFrom: 1 to: 5) asOrderedCollection. + sourceLines add: ' [...]'. + source := sourceLines joinSeparatedBy: Character cr]. + formatted := SHTextStylerST80 new classOrMetaClass: self selectedClassOrMetaClass; styledTextFor: source asText. - - lineCount := 0. - source doWithIndex: [:char :index | - char = Character cr ifTrue: [lineCount := lineCount + 1]. - lineCount > 10 ifTrue: [ - formatted := formatted copyFrom: 1 to: index-1. - formatted append: ' [...]'. - ^ formatted]]. + ^ (Text newFrom: ((self messageIconHelpAt: anIndex) ifNotEmpty: [:t | t , Character cr, Character cr])) + append: formatted; + yourself! - ^ formatted! Item was added: + ----- Method: Browser>>messageIconHelpAt: (in category 'message list') ----- + messageIconHelpAt: anIndex + + self class showMessageIcons + ifFalse: [^ nil]. + + ^ ToolIconHelp iconHelpNamed: (ToolIcons + iconForClass: self selectedClassOrMetaClass + selector: (self messageList at: anIndex))! Item was added: + Object subclass: #ToolIconHelp + instanceVariableNames: '' + classVariableNames: 'HelpTexts' + poolDictionaries: '' + category: 'Tools-Base'! Item was added: + ----- Method: ToolIconHelp class>>abstract (in category 'as yet unclassified') ----- + abstract + + ^ 'This method is abstract.' ! Item was added: + ----- Method: ToolIconHelp class>>arrowDown (in category 'as yet unclassified') ----- + arrowDown + + ^ 'This method is overriden by another method.'! Item was added: + ----- Method: ToolIconHelp class>>arrowUp (in category 'as yet unclassified') ----- + arrowUp + + ^ 'This method overrides a super method.'! Item was added: + ----- Method: ToolIconHelp class>>arrowUpAndDown (in category 'as yet unclassified') ----- + arrowUpAndDown + + ^ 'This method overrides and is overridden by other methods.'! Item was added: + ----- Method: ToolIconHelp class>>blank (in category 'as yet unclassified') ----- + blank + + ^ ''! Item was added: + ----- Method: ToolIconHelp class>>breakpoint (in category 'as yet unclassified') ----- + breakpoint + + ^ 'This method contains a breakpoint.'! Item was added: + ----- Method: ToolIconHelp class>>flag (in category 'as yet unclassified') ----- + flag + + ^ 'This method needs attention of some kind.' ! Item was added: + ----- Method: ToolIconHelp class>>helpTexts (in category 'as yet unclassified') ----- + helpTexts + + ^ HelpTexts ifNil: [HelpTexts := IdentityDictionary new]! Item was added: + ----- Method: ToolIconHelp class>>iconHelpNamed: (in category 'as yet unclassified') ----- + iconHelpNamed: aSymbol + + (self respondsTo: aSymbol) + ifTrue: [^self helpTexts at: aSymbol ifAbsentPut: [self perform: aSymbol]] + ifFalse: [^ ''] + ! Item was added: + ----- Method: ToolIconHelp class>>no (in category 'as yet unclassified') ----- + no + + ^ 'This method should not be implemented.' ! Item was added: + ----- Method: ToolIconHelp class>>notOverridden (in category 'as yet unclassified') ----- + notOverridden + + ^ 'This method is abstract and has not been overridden.' ! Item was added: + ----- Method: ToolIconHelp class>>primitive (in category 'as yet unclassified') ----- + primitive + + ^ 'This method implements a primitive.'!

1 0

The Trunk: Morphic-tpr.1058.mcz
by commits＠source.squeak.org 09 Dec '15

09 Dec '15

tim Rowledge uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-tpr.1058.mcz ==================== Summary ==================== Name: Morphic-tpr.1058 Author: tpr Time: 8 December 2015, 6:45:23.463 pm UUID: c438744a-71c4-45a0-ade8-7ecf52f50f89 Ancestors: Morphic-cwp.1057, Morphic-tpr.1057 Transfer from inbox, keep up to date. =============== Diff against Morphic-cwp.1057 =============== Item was added: + ----- Method: HandMorph>>gridPointRaw (in category 'gridded cursor') ----- + gridPointRaw + "return my latest position gridded" + ^self griddedPoint: self currentEvent position! Item was added: + ----- Method: HandMorph>>gridTo:origin: (in category 'gridded cursor') ----- + gridTo: grid origin: offset + "set a couple of properties to specify gridding for the temporaryCursor; instvars would be nicer" + self setProperty: #gridStep toValue: grid; + setProperty: #gridOffset toValue: offset! Item was added: + ----- Method: HandMorph>>griddedPoint: (in category 'gridded cursor') ----- + griddedPoint: aPoint + "return the equivalent point snapped to the grid, if indeed any gridding is set" + self valueOfProperty: #gridStep ifPresentDo: [:grid| |offset| + offset := self valueOfProperty: #gridOffset ifAbsent: [0@0]. + ^ offset + (aPoint + (grid //2) - offset truncateTo: grid)]. + ^aPoint! Item was changed: ----- Method: HandMorph>>position: (in category 'geometry') ----- position: aPoint "Overridden to align submorph origins to the grid if gridding is on." | adjustedPosition delta box | adjustedPosition := aPoint. + temporaryCursor ifNotNil: [adjustedPosition := (self griddedPoint: adjustedPosition) + temporaryCursorOffset]. - temporaryCursor ifNotNil: [adjustedPosition := adjustedPosition + temporaryCursorOffset]. "Copied from Morph to avoid owner layoutChanged" "Change the position of this morph and and all of its submorphs." delta := adjustedPosition - bounds topLeft. delta isZero ifTrue: [^ self]. "Null change" box := self fullBounds. (delta dotProduct: delta) > 100 ifTrue:[ "e.g., more than 10 pixels moved" self invalidRect: box. self invalidRect: (box translateBy: delta). ] ifFalse:[ self invalidRect: (box merge: (box translateBy: delta)). ]. self privateFullMoveBy: delta. ! Item was added: + ----- Method: HandMorph>>turnOffGridding (in category 'gridded cursor') ----- + turnOffGridding + "remove the gridding properties to stop gridding" + self removeProperty: #gridStep; removeProperty: #gridOffset!

1 0

Re: [Unicode] Class Unicode --> data from unicode.org
by EuanM 09 Dec '15

09 Dec '15

Gnu-Smalltalk also has the classes UnicodeCharacter UnicodeString which I'm having a good look at. On 7 December 2015 at 08:52, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > there is a class 'Unicode' both in Squeak and Pharo. > > http://wiki.squeak.org/squeak/6225 > > It surely needs attention as it loads the data from www.unicode.org to > initialize the Unicode knowhow of Squeak / Pharo.

6 8

Updating past 15464 (spur)
by tim Rowledge 09 Dec '15

09 Dec '15

This must have been noticed and I swear I saw messages about it not so long ago but I can’t find anything right now. Very frustrating! I have an image updated to 15464 and when attempting to update it stops at Kernel.spur-dtl.850, opening an MC merge window. Attempting to do a merge doesn’t seem to work - something in one of the conflicts is nil when it shouldn’t be and so trying the relatively obvious ‘All Newer’ fails. Manually choosing ‘Keep’ for each of the conflicts allows us to get a bit further. This time I get to Collections.spur-nice.569 where another merge window opens and, oh nice, an MNU from the timer event loop. At which point we are of course locked. It must be possible to proceed since we have newer trunk images to download. Did we not find a way to allow us to just do the update ‘normally’? tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim When you earnestly believe you can compensate for a lack of skill by doubling your efforts, there's no end to what you can't do

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
17
Older →

Jump to page: