October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Character>>#leadingChar

by Henrik Johansen

As an added bonus, asInteger / asUnicode / codePoint / charCode / asciiValue would all share the same definition; ^value :) Cheers, Henry P.S. codePoint is currently bugged, it should be ^self asUnicode I'd hardly say the leadingChar-tagged value in potentially different character sets it currently returns meets the ANSI definition of: "Return the encoding value of the receiver in the implementation defined execution character set." On Oct 21, 2013, at 11:18 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Oct 18, 2013, at 6:34 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> So once again we have an issue with Character>>#leadingChar, see >> >> https://pharo.fogbugz.com/f/cases/6368 >> >> Do we really need this ? >> Any Japanese, Chinese or Korean users willing to comment ? >> >> Thx, >> >> Sven >> > > I'm not any of those, but my short answer would be no. > > As for the long answer: > LeadingChar has too many responsibilities: > - Character set of string > - Font selection (see StrikeFontSet) > - Han unification disambiguation (through the above font selection) > > The conflation of these, and confusion of which leadingChar actually implies, easily leads to bugs, and has done so already. (see Character >> asUnicode as opposed to JapaneseEnvironment >> fromJISX0208String: for example). > I would bet 100â¬ StrikeFontSet no longer works as intended either, that is, being able to display > latin1 glyphs using StrikeFonts. > > Now, here's why I feel those areas are not worth keeping, especially in their current, buggy state: > - Non-unicode character sets > The main reasons for supporting this would be > 1) Size reduction. All Widestrings are 32bits per character, so that's moot. > 2) No need for converting codepoints when using Fonts stored with JISX0208 etc. codePoints . I've yet to see a free/truetype font using anything but Unicode, and since we'd be the creators of any theoretical StrikeFontSet covering other languages, we'd be able to avoid it anyways. > > If, in the future, it'd be desirable to support encodings other than Unicode for internal strings, I feel separate subclasses are a cleaner solution. > > - Font selection / Han unification disambiguation > IMHO, obsoleted by the use of standard TrueType fonts. As long as one does not use StrikeFontSets to display a string, it currently has no benefits. > Yes, one could potentially select different FreeTypeFonts based on it when a run is encountered as well, but the fonts themselves do not contain metadata pertaining to which variant of the glyphs they include, afaik (if they even support them; automatic fallback to another font when current font doesn't cover a glyph would be a higher area of priority) > Even in that case, it could be a property of the current locale instead, while it means you can't display both korean/japanese text in the same image correctly, it'd be a (imho) acceptable tradeoff. > > Cheers, > Henry >

Oct. 21, 2013

Re: [Pharo-dev] Character>>#leadingChar

by Sven Van Caekenberghe

Hi Henry, On 21 Oct 2013, at 11:18, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On Oct 18, 2013, at 6:34 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> So once again we have an issue with Character>>#leadingChar, see >> >> https://pharo.fogbugz.com/f/cases/6368 >> >> Do we really need this ? >> Any Japanese, Chinese or Korean users willing to comment ? >> >> Thx, >> >> Sven >> > > I'm not any of those, but my short answer would be no. Thanks for the reply and explanation, it seems you confirm what I suspected. > As for the long answer: > LeadingChar has too many responsibilities: > - Character set of string > - Font selection (see StrikeFontSet) > - Han unification disambiguation (through the above font selection) > > The conflation of these, and confusion of which leadingChar actually implies, easily leads to bugs, and has done so already. (see Character >> asUnicode as opposed to JapaneseEnvironment >> fromJISX0208String: for example). > I would bet 100â¬ StrikeFontSet no longer works as intended either, that is, being able to display > latin1 glyphs using StrikeFonts. > > Now, here's why I feel those areas are not worth keeping, especially in their current, buggy state: > - Non-unicode character sets > The main reasons for supporting this would be > 1) Size reduction. All Widestrings are 32bits per character, so that's moot. > 2) No need for converting codepoints when using Fonts stored with JISX0208 etc. codePoints . I've yet to see a free/truetype font using anything but Unicode, and since we'd be the creators of any theoretical StrikeFontSet covering other languages, we'd be able to avoid it anyways. > > If, in the future, it'd be desirable to support encodings other than Unicode for internal strings, I feel separate subclasses are a cleaner solution. > > - Font selection / Han unification disambiguation > IMHO, obsoleted by the use of standard TrueType fonts. As long as one does not use StrikeFontSets to display a string, it currently has no benefits. > Yes, one could potentially select different FreeTypeFonts based on it when a run is encountered as well, but the fonts themselves do not contain metadata pertaining to which variant of the glyphs they include, afaik (if they even support them; automatic fallback to another font when current font doesn't cover a glyph would be a higher area of priority) > Even in that case, it could be a property of the current locale instead, while it means you can't display both korean/japanese text in the same image correctly, it'd be a (imho) acceptable tradeoff. Although from what I understand about Han Unification and from the code, that last point would seem to be the case, but I am not 100% convinced. Most modern systems use Unicode everywhere, so they would all have that problem - a bit hard to believe. We need some feedback from native speakers as well. Sven > Cheers, > Henry >

Oct. 21, 2013

[update 3.0] #30509

by Marcus Denker

30509 ----- 7444 Synchronizing DateAndTime with system OS date and time https://pharo.fogbugz.com/f/cases/7444 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Localization-MarcusDen… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1651.diff

Oct. 21, 2013

Re: [Pharo-dev] Character>>#leadingChar

by Henrik Johansen

On Oct 18, 2013, at 6:34 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > So once again we have an issue with Character>>#leadingChar, see > > https://pharo.fogbugz.com/f/cases/6368 > > Do we really need this ? > Any Japanese, Chinese or Korean users willing to comment ? > > Thx, > > Sven > I'm not any of those, but my short answer would be no. As for the long answer: LeadingChar has too many responsibilities: - Character set of string - Font selection (see StrikeFontSet) - Han unification disambiguation (through the above font selection) The conflation of these, and confusion of which leadingChar actually implies, easily leads to bugs, and has done so already. (see Character >> asUnicode as opposed to JapaneseEnvironment >> fromJISX0208String: for example). I would bet 100â¬ StrikeFontSet no longer works as intended either, that is, being able to display > latin1 glyphs using StrikeFonts. Now, here's why I feel those areas are not worth keeping, especially in their current, buggy state: - Non-unicode character sets The main reasons for supporting this would be 1) Size reduction. All Widestrings are 32bits per character, so that's moot. 2) No need for converting codepoints when using Fonts stored with JISX0208 etc. codePoints . I've yet to see a free/truetype font using anything but Unicode, and since we'd be the creators of any theoretical StrikeFontSet covering other languages, we'd be able to avoid it anyways. If, in the future, it'd be desirable to support encodings other than Unicode for internal strings, I feel separate subclasses are a cleaner solution. - Font selection / Han unification disambiguation IMHO, obsoleted by the use of standard TrueType fonts. As long as one does not use StrikeFontSets to display a string, it currently has no benefits. Yes, one could potentially select different FreeTypeFonts based on it when a run is encountered as well, but the fonts themselves do not contain metadata pertaining to which variant of the glyphs they include, afaik (if they even support them; automatic fallback to another font when current font doesn't cover a glyph would be a higher area of priority) Even in that case, it could be a property of the current locale instead, while it means you can't display both korean/japanese text in the same image correctly, it'd be a (imho) acceptable tradeoff. Cheers, Henry

Oct. 21, 2013

[update 3.0] #30508

by Marcus Denker

30508 ----- 11959 CMD+/ => Comment Selection or Line In PluggableTextMorph (Workspace, Nautilus code pane, ...) https://pharo.fogbugz.com/f/cases/11959 11903 unused MorphicUnknownEvent https://pharo.fogbugz.com/f/cases/11903 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Text-Edition-MarcusDenker.23.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.165… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-MarcusDen…

Oct. 21, 2013

Re: [Pharo-dev] Anyone else teaching programming in Pharo?

by Alexandre Bergel

> I'm using smaller home-made examples for the lab that I port to the latests version of Pharo. Are these available somewhere? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 21, 2013

Re: [Pharo-dev] WhatsUp from: 2013-10-21 until: 2013-10-31

by Damien Cassou

### Here's what I've been up to since the last WhatsUp: - continue working on Pillar, an extraction of the Pier wiki parser and visitor (http://www.smalltalkhub.com/#!/~Pier/Pillar) - fix some jobs after the #shouldnt:raise: deprecation - review fixes from Ben Coman and Torsten to the Pharo Launcher (http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher) The launcher is getting better and better everyday. You want to try it! - start extracting the Pharo Launcher to its own Debian package - help Sebastian Tleye get a engineer position on a Smalltalk project in France - fix a bug in the Pharo VM packaged on Ubuntu - fix the missing icon for Pharo on Ubuntu (with Gnome) ### What's next, until 2013-10-31 (*): - extracting the Pharo Launcher to its own Debian package - release a new version of the Pharo Launcher after all the work of Ben and Torsten - more reviewing of Ben Coman's code on the Pharo Launcher (hopefully :-)) - continue working on Pillar, an extraction of the Pier wiki parser and visitor (http://www.smalltalkhub.com/#!/~Pier/Pillar) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 21, 2013

Re: [Pharo-dev] SuperCollider on Pharo [was: realtime]

by dimitris chloupis

The problem here is not how to communicate via OSC to Supercollider, OSC is actually a simple to implement protocol.Â When I bought Pharo By Example I also bought the Supercollider book. To put things in perspective that book is 700 pages long and twice in width compared to the Pharo By Example book. And like Pharo By Example , its just an introduction to SuperCollider. SuperCollider is a monster. So again we go back to the "IT DEPENDS" phenomenon , the real question is what you want to do with it. Anything is doable. Hard is just something that take more time than something that is easy. And thats its.Â You CAN do anything you want if you commit to it and willing to spent the time. I decided to postpone making Orpheas (Interface to SuperCollider) because I wanted first to have good progress with Morpeas (a replacement of Morphic based on opengl). This is the issue here. If you want to create tools that people will use , especially music tools you need fancy easy to use GUIs. An average user is unlikely will be willing to sit down and learn SuperCollider cause it does a lot more than he wants. He most likely will want to use familiar music tools and that means you will need to build a lot of GUI tools. Cause SuperCollider is a programming language in the end not a GUI tool (though it has many GUI tools).Â I think a sound practice here (pun intended) is not to ditch SClang. There tons of tools that are made with SClang , so my initial plan was to have a trio SuperCollider [server] - Sclang - Pharo. Server as the audio engine, sclang for all the nice supercollider tools already available and Pharo for the GUI part (using Morpheas).Â Also Supercollider is far from the only option here, I have found similar solution for PD (aka Pure Data) which like supercollider is realtime and it uses a flow chart based interface to create its presets (nodes connected with cables) its commercial counterpart is the very popular MAX/MSP. And of course there are tons more other options too out there. I was even considering making a VST/AU bridge , so that users could use already familiar tools. 99% of modern music nowdays passes and/or is made with VST/AU synths and audio effects so having that is a huge plus. Again VST is a simple C API to implement but still needs someone to actually sit down and implement it. Bottom line is that all these things take A LOT of time, its not the kind of projects that you finish in a week or a month , they can easily take years (or decades). So it depends on you and how deep you want to go in the rabbit hole. Interfacing with OSC and Supercollider is only the start of the journey. On Monday, 21 October 2013, 3:06, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: SqueakMap for OSC (http://map.squeak.org/sm/accountbyid/13fa7a75-1e76-471e-8f42-b676f4d8e373/p…) states: One can remote control supercollider and other sound generators implementing OSC using UDP. Release 2-1.1 - Now even runs with Supercollider! So, it looks like the work has already been done!

Oct. 21, 2013

[update 3.0] #30507

by Marcus Denker

30507 ----- 11958 Add support for window menu addition https://pharo.fogbugz.com/f/cases/11958 11956 Move CompiledMethods deprecated methods to Deprecated30 package https://pharo.fogbugz.com/f/cases/11956 11957 Move OpalCompiler deprecated methods to Deprecated30 package https://pharo.fogbugz.com/f/cases/11957 11492 Kill UpdatingStringMorph, UpdatingMenu, and NameInHaloMorph https://pharo.fogbugz.com/f/cases/11492 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-MorphicAdapters-MarcusDe… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.187.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.164… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Deprecated30-MarcusDenker.15.…

Oct. 21, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Marcus Denker

I have turned off these emails for now, they are too many and thus get ignored (I have never seen anyone but me filing an issue tracker entry for a newly failing testâ¦) Marcus On Oct 21, 2013, at 8:32 AM, no-reply(a)ci.inria.fr wrote: > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… > > 2 regressions found. > Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits > Zinc.Tests.ZnServerTests.testEntityTooLarge >

Oct. 21, 2013