September 2014 - Pharo-users

Threaded callbacks with FFI

by Annick Fron

Hi, I am calling C from pharo with a callback, and it seems the callback is called in another thread. I canât wrap the block in a process, because the return will be wrong, how can I do ??? Annick

Sept. 25, 2014

Re: [Pharo-users] What to use?

by Yuriy Tymchuk

There is a new Charter builder now. Itâs not very stable yet as far as I can tell, but itâs the future of charts in Roassal https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Charter/020… <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Charter/020…> Uko > On 25 Sep 2014, at 09:19, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > > Esteban Lorenzano <estebanlm(a)gmail.com> writes: > >> probably GraphET >> >> https://www.facebook.com/media/set/?set=a.566523986767536.1073741839.340543… > Thanks, that seems to be it > > Regards > Friedrich >

Sept. 25, 2014

Re: [Pharo-users] What to use?

by Friedrich Dominicus

Esteban Lorenzano <estebanlm(a)gmail.com> writes: > probably GraphET > > https://www.facebook.com/media/set/?set=a.566523986767536.1073741839.340543… Thanks, that seems to be it Regards Friedrich

Sept. 25, 2014

Re: [Pharo-users] What to use?

by Esteban Lorenzano

probably GraphET https://www.facebook.com/media/set/?set=a.566523986767536.1073741839.340543… On 25 Sep 2014, at 09:08, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > If one is intersted in graphics of diverse functions? > > E.g plotting x^2,x^3 and the like. I checked the DrGeo stuff but that's > geometry and not just analysis of functions and the like? > > Does there exist something for that? > > Regards > Friedrich > >

Sept. 25, 2014

What to use?

by Friedrich Dominicus

If one is intersted in graphics of diverse functions? E.g plotting x^2,x^3 and the like. I checked the DrGeo stuff but that's geometry and not just analysis of functions and the like? Does there exist something for that? Regards Friedrich

Sept. 25, 2014

Re: [Pharo-users] Packaging Pharo for many distributions at once

by Christophe Demarey

Le 24 sept. 2014 Ã 18:51, Damien Cassou a Ã©crit : > On Wed, Sep 24, 2014 at 12:47 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> All non-native package managers have that issue. > > > nix included I know ... That's why native packages are still interesting even if it's difficult to manage various package descriptions and build.

Sept. 25, 2014

Re: [Pharo-users] Ridiculous we are

by Sven Van Caekenberghe

On 25 Sep 2014, at 01:04, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 25/09/2014 00:06, Sven Van Caekenberghe a Ã©crit : >> Alain, > >> The character encoding situation in Pharo is pretty good actually. The only problem is that there is some old school code left that encodes strings into strings, but today you can easily write much better and conceptually correct code. >> >> You could have a look at this draft chapter of the upcoming 'Enterprise Pharo' book that I am currently writing: >> >> http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ >> >> Concerning file system paths, FilePathEncoder and FilePluginPrimitives already do the right thing. >> >> Now, your idea about using UTF-8 to represent internal Strings is something that has been discussed before and in many other languages as well. The short answer is that due to it being variable length, the inefficiency is (probably) just too high. Simple indexed access becomes a problem, let alone more complex string manipulations. I am not saying that it cannot be done, I think it is just not worth the trouble. The current solution in Pharo with ByteString and WideString is quite nice (check the chapter I mentioned before). >> >> Sven >> > Very interesting ! > It seems that most of what I was saying is already here :) > I was not saying that Pharo should use utf8 (I mentionned utf8 because it is a standard, but I find the variable length encoding very weird), I was rather talking of using WideString in UTF 16 or 32 and that's done. > I saw asWideString but didn't know about automatic convertion or codepoint selector and internal wide string support. > Does it means that Pharo Greek users (for example) use WideString for Strings without having to specify it or make explicit convertions (except of course when dealing with bytes if they want to) ? > If yes, very good, job is almost done :) > (personnally I would also deprecate ByteString, and get rid of it, just my opinion). > Thanks for the link, another good chapter . > > Regards, > > Alain Yes, the Greek users won't notice a difference, it is all transparent. ByteString is important because it is an optimalization of the most common case. As a normal user you should only think of abstract Strings and never use #asByteString (but use proper encoding). Feedback on the chapter is always welcome. Sven

Sept. 25, 2014

Re: [Pharo-users] Ridiculous we are

by Alain Rastoul

Le 25/09/2014 00:06, Sven Van Caekenberghe a Ã©crit : > Alain, > The character encoding situation in Pharo is pretty good actually. The only problem is that there is some old school code left that encodes strings into strings, but today you can easily write much better and conceptually correct code. > > You could have a look at this draft chapter of the upcoming 'Enterprise Pharo' book that I am currently writing: > > http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ > > Concerning file system paths, FilePathEncoder and FilePluginPrimitives already do the right thing. > > Now, your idea about using UTF-8 to represent internal Strings is something that has been discussed before and in many other languages as well. The short answer is that due to it being variable length, the inefficiency is (probably) just too high. Simple indexed access becomes a problem, let alone more complex string manipulations. I am not saying that it cannot be done, I think it is just not worth the trouble. The current solution in Pharo with ByteString and WideString is quite nice (check the chapter I mentioned before). > > Sven > Very interesting ! It seems that most of what I was saying is already here :) I was not saying that Pharo should use utf8 (I mentionned utf8 because it is a standard, but I find the variable length encoding very weird), I was rather talking of using WideString in UTF 16 or 32 and that's done. I saw asWideString but didn't know about automatic convertion or codepoint selector and internal wide string support. Does it means that Pharo Greek users (for example) use WideString for Strings without having to specify it or make explicit convertions (except of course when dealing with bytes if they want to) ? If yes, very good, job is almost done :) (personnally I would also deprecate ByteString, and get rid of it, just my opinion). Thanks for the link, another good chapter . Regards, Alain

Sept. 24, 2014

Re: [Pharo-users] Ridiculous we are

by Sven Van Caekenberghe

Alain, On 24 Sep 2014, at 23:00, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 24/09/2014 19:09, Benjamin Pollack a Ã©crit : > >> If Pharo used > ByteArrays to represent paths, with convenience methods for working with >> UTF-8 (since I do agree that's the most likely thing for a user/dev to >> want), then you'd be able to work with all files no matter what, *and* >> have a convenient way of doing so for the common case. > Hi Ben, > I strongly disagree with you on this point: using byte arrays (or byte strings) is a pain in an international context. > The OS knows about its encoding: locale for unix, code page for windows. > Windows code pages depends on country, for english windows 1252 (similar to iso-8859-1), for other european countries, other variations of 8859-xx... (welcome to ISO soup), same for unix. > > Java uses UTF8 strings and dotNet uses UTF16 strings (don't know for Python) where chars are not bytes and they are not used as byte arrays but as Character arrays. > Both do conversions from OS character set encoding to internal encoding for strings (paths and whatever). > > There is already an UTF8 and UTF16 encoding support in Pharo, but the > standard String class uses bytes, and lot of files, directories and > system methods use ByteString class and that is the problem here. > UTF8 encoding in Pharo encodes to a variable lenght ByteString, which is not the same as an (hypothetical) Utf8String where all (variable length) chars would be utf8 encoded. > Using a new UTF8 or UTF16 string class could be a major rework, > but taking a decision about about internal string encoding is needed. > As Sven says, there is no emergency and you have a workaround, but > perhaps using the existing WideString encoded as UTF16 (or UTF32?) in > some well defined classes/methods could be a good start for this rework? > IMHO the workaround of using utf8 encoded byte strings is not a good way to deal with this problem and should not be granted as "the solution". The character encoding situation in Pharo is pretty good actually. The only problem is that there is some old school code left that encodes strings into strings, but today you can easily write much better and conceptually correct code. You could have a look at this draft chapter of the upcoming 'Enterprise Pharo' book that I am currently writing: http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ Concerning file system paths, FilePathEncoder and FilePluginPrimitives already do the right thing. Now, your idea about using UTF-8 to represent internal Strings is something that has been discussed before and in many other languages as well. The short answer is that due to it being variable length, the inefficiency is (probably) just too high. Simple indexed access becomes a problem, let alone more complex string manipulations. I am not saying that it cannot be done, I think it is just not worth the trouble. The current solution in Pharo with ByteString and WideString is quite nice (check the chapter I mentioned before). Sven

Sept. 24, 2014

Re: [Pharo-users] Ridiculous we are

by Alain Rastoul

Le 24/09/2014 19:09, Benjamin Pollack a Ã©crit : > If Pharo used > ByteArrays to represent paths, with convenience methods for working with > UTF-8 (since I do agree that's the most likely thing for a user/dev to > want), then you'd be able to work with all files no matter what, *and* > have a convenient way of doing so for the common case. Hi Ben, I strongly disagree with you on this point: using byte arrays (or byte strings) is a pain in an international context. The OS knows about its encoding: locale for unix, code page for windows. Windows code pages depends on country, for english windows 1252 (similar to iso-8859-1), for other european countries, other variations of 8859-xx... (welcome to ISO soup), same for unix. Java uses UTF8 strings and dotNet uses UTF16 strings (don't know for Python) where chars are not bytes and they are not used as byte arrays but as Character arrays. Both do conversions from OS character set encoding to internal encoding for strings (paths and whatever). There is already an UTF8 and UTF16 encoding support in Pharo, but the standard String class uses bytes, and lot of files, directories and system methods use ByteString class and that is the problem here. UTF8 encoding in Pharo encodes to a variable lenght ByteString, which is not the same as an (hypothetical) Utf8String where all (variable length) chars would be utf8 encoded. Using a new UTF8 or UTF16 string class could be a major rework, but taking a decision about about internal string encoding is needed. As Sven says, there is no emergency and you have a workaround, but perhaps using the existing WideString encoded as UTF16 (or UTF32?) in some well defined classes/methods could be a good start for this rework? IMHO the workaround of using utf8 encoded byte strings is not a good way to deal with this problem and should not be granted as "the solution".

Sept. 24, 2014