February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] The Pharo Unicode Project

by Ben Coman

On Wed, Feb 17, 2016 at 5:16 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > In Pharo we can deal with and represent any Unicode character and string, but there are still some important pieces of functionality missing. > > The goal of the Pharo Unicode project is to gradually improve and expand Unicode support in Pharo. We started in December last year to lay the foundation and are now ready to go public with what we built. > > The first delivery is an implementation of Unicode Normalization, together with an implementation of the Unicode Character Database. > > Please read the following article for more information (the appendix explains how to get the code). > > An Implementation of Unicode Normalisation > > Streaming NFC, NFD, NFKC & NFKD, normalization QC and normalization preserving concatenation. > > https://medium.com/concerning-pharo/an-implementation-of-unicode-normalizat… > > The development branch also contains a work in progress implementation of Unicode Collation. > > Much work remains to be done and contributions are more than welcome. > > Sven & Henrik This is really great. Thanks Sven & Henrik. > The right pane shows a large glyph view of the character involved. This is very cool !! Does it rely on font support, or is it bitmap or SVG based? Maybe it could dynamically download SVG data as needed from somewhere like here... http://www.fileformat.info/info/unicode/char/00f6/index.htm > We also added an extension to our environmentâs search system to allow you to look up characters by name: Is there a #unicode filter for Spotter? check repeated phrase... > and replace it with and replace it with I bumped into an interesting "Good, Bad, Ugly" comparison of Unicode support in other programming languages (though circa 2011) https://www.azabani.com/pages/gbu/ and this sparked a thought to wonder if the consortium would consider it worthwhile paying someone external (like that author) with broad cross platform Unicode experience to consult on getting Pharo to a pragmatic point where we look attractive in such comparisons, which may also provide a side-channel advertisement for Pharo when such comparisons are presented at conferences (??) cheers -ben

Feb. 18, 2016

Re: [Pharo-dev] [ANN] The Pharo Unicode Project

by Henrik Sperre Johansen

Because, who doesn't want to spend an evening with a workspace like this: http://pastebin.com/gdxCrTgM trying to figure out why some of the last 7 out of 189k official collate tests fail? Seriously though, personally I was just tired of having to answer "Sort of, but not really" every time the question of Unicode support is raised, specifically the last discussion that lead nowhere back in December. Better to show in code how you think a decent implementation might look like, and Sven made it easier to get rolling when he wrote import code for many of the data tables needed, parsing text is one of the things I dislike most... Cheers, Henry P.S. Unicode Collation is more of an intellectual exercise. For practical collation you need the locale tailorings from CLDR, which is kept in a, frankly, abominable format. The object model / actual collate algorithms should carry over nicely though, so it's not a complete waste. On Wed, Feb 17, 2016 at 7:56 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I read the whole Article, seems like a tricky, to not say hard, > subject. The article is very detailed and well written though. > > What is the rationale behind embracing such a challenging feature like > supporting Unicode? > > Regards! > > > Esteban A. Maringolo > > > 2016-02-17 15:24 GMT-03:00 Max Leske <maxleske(a)gmail.com>: > > Good stuff guys! > > > >> On 17 Feb 2016, at 10:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> Hi, > >> > >> In Pharo we can deal with and represent any Unicode character and > string, but there are still some important pieces of functionality missing. > >> > >> The goal of the Pharo Unicode project is to gradually improve and > expand Unicode support in Pharo. We started in December last year to lay > the foundation and are now ready to go public with what we built. > >> > >> The first delivery is an implementation of Unicode Normalization, > together with an implementation of the Unicode Character Database. > >> > >> Please read the following article for more information (the appendix > explains how to get the code). > >> > >> An Implementation of Unicode Normalisation > >> > >> Streaming NFC, NFD, NFKC & NFKD, normalization QC and normalization > preserving concatenation. > >> > >> > https://medium.com/concerning-pharo/an-implementation-of-unicode-normalizat… > >> > >> The development branch also contains a work in progress implementation > of Unicode Collation. > >> > >> Much work remains to be done and contributions are more than welcome. > >> > >> Sven & Henrik > > > > > >

Feb. 18, 2016

Re: [Pharo-dev] [ANN] The Pharo Unicode Project

by Sven Van Caekenberghe

> On 17 Feb 2016, at 19:56, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > I read the whole Article, seems like a tricky, to not say hard, subject. Yes. The Unicode specs are big and complex. Step one is to read & understand them, at least well enough to find your way. Doing some implementation is not too hard, but getting 100% scores on the very extensive test suites was/is quite hard. > The article is very detailed and well written though. Thx. > What is the rationale behind embracing such a challenging feature like supporting Unicode? Unicode is the de facto standard for internationalisation of computer software. Any serious platform has to tackle (big parts of) Unicode. > Regards! > > > Esteban A. Maringolo > > > 2016-02-17 15:24 GMT-03:00 Max Leske <maxleske(a)gmail.com>: >> Good stuff guys! >> >>> On 17 Feb 2016, at 10:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi, >>> >>> In Pharo we can deal with and represent any Unicode character and string, but there are still some important pieces of functionality missing. >>> >>> The goal of the Pharo Unicode project is to gradually improve and expand Unicode support in Pharo. We started in December last year to lay the foundation and are now ready to go public with what we built. >>> >>> The first delivery is an implementation of Unicode Normalization, together with an implementation of the Unicode Character Database. >>> >>> Please read the following article for more information (the appendix explains how to get the code). >>> >>> An Implementation of Unicode Normalisation >>> >>> Streaming NFC, NFD, NFKC & NFKD, normalization QC and normalization preserving concatenation. >>> >>> https://medium.com/concerning-pharo/an-implementation-of-unicode-normalizat… >>> >>> The development branch also contains a work in progress implementation of Unicode Collation. >>> >>> Much work remains to be done and contributions are more than welcome. >>> >>> Sven & Henrik >> >> >

Feb. 17, 2016

Re: [Pharo-dev] What are immediate subclass and word variable subclass?

by Eliot Miranda

Hi Alexandre, > On Feb 17, 2016, at 7:30 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > I have stumbled on: > > Float immediateSubclass: #SmallFloat64 > instanceVariableNames: '' > classVariableNames: '' > package: 'Kernel-Numbersâ > > > Float variableWordSubclass: #BoxedFloat64 > instanceVariableNames: '' > classVariableNames: '' > package: 'Kernel-Numbersâ > > > What are immediate subclass and word variable? Immediates are objects that are stored in an object pointer using a tag to distinguish them from ordinary object pointers. In v3 the only immediate is SmallInteger. In 32-but spur there are SmallInteger and Character. An implication of this is that in spur all Characters can be compared using #==. In 64-bit Spur there is also SmallFloat64. If a float's exponent is in the middle 8-bits of the 11-bit exponent range then it will be immediate. If a float's exponent is outside of the middle 8-bits it will be boxed. Objects on the heap are either pointers or bits. For example instances of Point, Array, BlockClosure etc are pointer objects. But Bitmap, ByteString, WideString etc are bits objects. In v3 bits objects are either a sequence of bytes (ByteArray, ByteString, ByteSymbol etc) or 32-bit words (WideString, Float, Bitmap etc). Spur supports byte, short, word and double-word bits objects even though currently only byte and word classes exist. 16-bit strings will be useful on Windows, for example. HTH > Cheers, > Alexandre _,,,^..^,,,_ (phone)

Feb. 17, 2016

How to find all primitives which accepts strings as arguments?

by Denis Kudriashov

Hi. Primitives is statically typed functions. VM has strict contract on argument types. Is it possible to query system for primitives by given criteria like string arguments? Information of primitive signature can be used by type inference libraries

Feb. 17, 2016

[ANN] OSUnix and OSLinuxUbuntu on new UFFI

by Torsten Bergmann

These two projects (who were based on NativeBoost in Pharo 4) are now updated to new UFFI in Pharo 5 which means they are loadable in recent Pharo 5 image and all tests pass. So if you are working on Linux/Unix you might wan to check them out in latest Pharo 5 by loading them from Catalog browser. A BIG THANKS to Esteban for helping me in the conversion and updating the new Unified FFI (UFFI) according to the issues that were found during the conversion. More is in the pipe ... step by step it goes! Bye T.

Feb. 17, 2016

Re: [Pharo-dev] Shortcuts are broken under Windows

by Nicolai Hess

2016-02-17 18:33 GMT+01:00 Blondeau Vincent <vincent.blondeau(a)worldline.com> : > Hi, > > > > Due to recent changes on shortcuts, on the new image several shortcuts > (CTRL+V,Z,M,W,Enter and the Alt ones) are not active at least in the > debugger and in the senders listâ¦ > ctrl+v ctrl+z ctrl+w are working for me ctrl+m does not work, this is known what "the Alt ones" do you mean? > I would like to fix this but I donât know what changedâ¦ > > How do I change the configuration? Is it in <keymap> pragmated methods? > > Or it is another bug? > > > > Cheers, > > Vincent > > > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. >

Feb. 17, 2016

Re: [Pharo-dev] Improving Ghost proxies

by Esteban Lorenzano

> On 15 Feb 2016, at 18:15, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Mon, Feb 15, 2016 at 1:22 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > our policy is > Any package used in the core of Pharo should be saved under Pharo. > > > > Stef, I think that's not correct. It might be the vision, but it's not the current state. QuallityAssistant, GT-Tools, etc are all examples of tools that come inside Pharo and are NOT under Pharo Shub team. it is correct. just that, since we are humans (and we consider some places like the glamour team part of Pharo), and stfx is just the side of one of our board members (and is super fast to access), some packages are allowed to remain outside the âdirect" umbrella. Some other will be moved to Pharo, PharoExtras or own of our teams as soon as I can find the time to do it :) Also, please note that this follows not a technical but a political reason in first term: All what is âPharoâ is/has to be under control of the Pharo community and not individualsâ¦ no matter how cool that individual is :) Then there are also some technical reasons: - sthub, while limited, is a lot faster to access than all the others (and this is an issue specially when integrating). - in long term, we might want to move to git/whatever, but our tools (while very ok for particular development) does not have reach enough maturity to do the step. We have some plans to improve it next year but wellâ¦ we had same plans last year and the the urgent won to the important. anywayâ¦ yes, Pharo stuff should be under Pharo umbrella, Stef is correctâ¦ even when it does not happens all the time because we have been slow on implement it. Esteban, back from vacations > > Unless by "in the core of Pharo" you mean something smaller than current Pharo image? > > Cheers, > > > Stef > > Le 15/2/16 11:15, Denis Kudriashov a Ã©crit : >> Hello. >> >> I think it is important to get single proxy framework for Pharo. It should provide required integration support for our tools. >> >> I want push Ghost in that direction. Debuggers and inspectors should work correctly with proxies which based on Ghost. >> >> Now Ghost is stored in CAR team repository. Should we move it to Pharo? >> >> P.S. Ghost has one failed tests due to Spur problem 17536 <https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…>. >> >> Best regards, >> Denis > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Feb. 17, 2016

Re: [Pharo-dev] [ANN] The Pharo Unicode Project

by Esteban A. Maringolo

I read the whole Article, seems like a tricky, to not say hard, subject. The article is very detailed and well written though. What is the rationale behind embracing such a challenging feature like supporting Unicode? Regards! Esteban A. Maringolo 2016-02-17 15:24 GMT-03:00 Max Leske <maxleske(a)gmail.com>: > Good stuff guys! > >> On 17 Feb 2016, at 10:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> In Pharo we can deal with and represent any Unicode character and string, but there are still some important pieces of functionality missing. >> >> The goal of the Pharo Unicode project is to gradually improve and expand Unicode support in Pharo. We started in December last year to lay the foundation and are now ready to go public with what we built. >> >> The first delivery is an implementation of Unicode Normalization, together with an implementation of the Unicode Character Database. >> >> Please read the following article for more information (the appendix explains how to get the code). >> >> An Implementation of Unicode Normalisation >> >> Streaming NFC, NFD, NFKC & NFKD, normalization QC and normalization preserving concatenation. >> >> https://medium.com/concerning-pharo/an-implementation-of-unicode-normalizat… >> >> The development branch also contains a work in progress implementation of Unicode Collation. >> >> Much work remains to be done and contributions are more than welcome. >> >> Sven & Henrik > >

Feb. 17, 2016

Re: [Pharo-dev] FFI BoxedFloat64 bug?

by Alexandre Bergel

> I don't understand. All BoxedFloat have 8 bytes, that's why they are called BoxedFloat64. There are no 4-bytes floats in Pharo. Even in 32 bits. I have some code that involve FFI and floats that was working before Spur. I got the error mentioned by Alex. Defining this pointer method gives a weird behavior. It would be great to have this fixed. Alexandre > > 2016-02-12 18:06 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> On 12 Feb 2016, at 17:50, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> On Fri, Feb 12, 2016 at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Float>>#pointer >> ^ (ByteArray new: FFIExternalType pointerSize) >> floatAt: 1 put: self; >> yourself >> >> Yes it does the trick :) Thanks! > > yes and no (I made a mistake): that works because incidentally pointers and floats have same size (4 bytes)â¦ but can happen that it is not (doubles have 8 bytes)â¦ but is ok for now :) > I will fix it correctly next week. > > Esteban > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 17, 2016