- Pharo-dev - lists.pharo.org

Re: [Pharo-project] file encodings

by Philippe Marschall

Tudor Girba wrote: > Hi Nicolas, > > Thanks for the tips. > > I am a bit alien to the topic of encodings, so I will ask a couple of > silly questions. > > How exactly do I deal with another encoding? For example, why does > this work with Utf-8, and what would I do if I encountered another > encoding? > > Or more general, how can I find out what kind of converter I need for > a given file? Welcome to a world full of shit. Executive summary: you're fucked. To read a file as a String instead of a ByteArray you need a way to map bytes to characters aka the file encoding. The problem is there is no way of knowing what the file encoding is. There just isn't because the operating system doesn't know and it does all the file handling. The only thing that you can know is when a file is not UTF-8. That is when you treat it as UTF-8 and get an UTF-8 error. You can pretend the problem doesn't exist and just use a random encoding aka the platform default encoding. That would work if all your files were are created on your computer and all your programs used the platform default encoding. E.g. you don't download stuff from the internet or copy stuff off storage media (USB sticks, CDs, DVDs, ...). The funny thing is that XML partially solves the problem because the encoding can be put into the preamble. In fact it should if the file is not ASCII. You can make a guess whether Yaxo supports binary input and detecting the encoding either from the BOM or the preamble. Cheers Philippe

Nov. 30, 2009

[Pharo-project] Is there something wrong in debugging in the Morphic thread?

by Simon Denier

Unfortunately, this is an issue which I cant easily reproduce, at least not without a third party tool (1525). Now I would like the general opinion/experience of debugging Morphic code especially in threads. Usually an exception raised from within Morphic code pops up a debugger as usual. However, from time to time, or for more complicated stuff, the situation runs out of hand and tons of debugger pop up everywhere because the same faulty gets obviously executed again and again. Now can somebody with some Morphic knowledge explain how this is supposed to work and how to deal with such issues? -- Simon

Nov. 30, 2009

Re: [Pharo-project] MPEG in Pharo depricated why?

by John M McIntosh

Well what I need is some windows user to build a windows VM, then install the Alien VMMaker additions, rebuild the VM and test to confirm it works or not. Without a such effort it won't happen On 2009-11-30, at 8:17 AM, StÃ©phane Ducasse wrote: >> >>> >>> Yes but that someone is busy so if someone else would publish the code in the inbox the someone would be happy >>> but thanks for the point. >> >> I had worked on this a bit (Sophie clipboard, sophie quicktime graphics reader, macintosh navigation services) but. >> >> (a) it requires FFI in the image, did we decide FFI and Alien should be in Pharo? I think that is an open question. > > Is alien working on windows? > May be we could have FFI and Alien > > FFI in the process of making sure that alien will work everywhere. > May be this is the best way to make sure that Alien will not make progress :) > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Nov. 30, 2009

Re: [Pharo-project] Feature request: Waiting cursor on load

by Alexandre Bergel

Thanks Johan, this is indeed a Pharo/Squeak problem. Time to times, the morph causing an error is not draw in red but loops. Could be that WorldState>>displayWorldSafely: does not find the guilty morph. Cheers, Alexandre On 30 Nov 2009, at 15:57, Johan Fabry wrote: > Hi Doru, > > thanks for the workaround! > > Thanks for pointing me to the moose google code side. Expect some > moose-related bugreports from me in the issue tracker, for example in > a few minutes my inability to debug Mondrian scripts in Pharo. (I > leave figuring out who is the end responsible to you guys ...). http://code.google.com/p/pharo/issues/detail?id=1525 > > On 30 Nov 2009, at 13:55, Tudor Girba wrote: > >> Hi Johan, >> >> Thanks for the report. >> >> A better forum for Moose related problems would be the moose-dev(a)iam.unibe.ch >> mailing list. You can subscribe here: >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> Also, to create an issue related to Moose, please use: >> http://code.google.com/p/moose-technology/issues/list >> >> Coming to your issue, this is due to Metacello having no progress >> bar. >> However, if you open a Transcript, you will get a progress report. >> So, >> now I changed a bit the ConfigurationOfMoose and it opens it for you >> when you loadDefault. You can get the change in: >> ConfigurationOfMoose-tg.33 >> >> Cheers, >> Doru >> >> >> On 30 Nov 2009, at 16:19, Alexandre Bergel wrote: >> >>>> finally able to get going on Pharo, I wanted to load Moose. I got >>>> the >>>> ConfigurationOfMoose package, and run the loadDefault method. >>> >>> Very good start! >>> >>>> I have no problem with a 'load' taking for ever, I know I am on the >>>> other side of the ocean. But please change the cursor to a 'wait' >>>> cursor while doing the load. It takes a loooooooong time before the >>>> first progress bar shows, I almost panicked. And now a progress bar >>>> just dissapeared, but there is still nothing I can do. The 'wait' >>>> cursor would go a long way in easing my mind. And it's probably >>>> just >>>> one line of code ... >>> >>> >>> Yeah, this is a well known problem. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "One cannot do more than one can do." >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 30, 2009

Re: [Pharo-project] Feature request: Waiting cursor on load

by Johan Fabry

Hi Doru, thanks for the workaround! Thanks for pointing me to the moose google code side. Expect some moose-related bugreports from me in the issue tracker, for example in a few minutes my inability to debug Mondrian scripts in Pharo. (I leave figuring out who is the end responsible to you guys ...). http://code.google.com/p/pharo/issues/detail?id=1525 On 30 Nov 2009, at 13:55, Tudor Girba wrote: > Hi Johan, > > Thanks for the report. > > A better forum for Moose related problems would be the moose-dev(a)iam.unibe.ch > mailing list. You can subscribe here: > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > Also, to create an issue related to Moose, please use: > http://code.google.com/p/moose-technology/issues/list > > Coming to your issue, this is due to Metacello having no progress bar. > However, if you open a Transcript, you will get a progress report. So, > now I changed a bit the ConfigurationOfMoose and it opens it for you > when you loadDefault. You can get the change in: > ConfigurationOfMoose-tg.33 > > Cheers, > Doru > > > On 30 Nov 2009, at 16:19, Alexandre Bergel wrote: > >>> finally able to get going on Pharo, I wanted to load Moose. I got >>> the >>> ConfigurationOfMoose package, and run the loadDefault method. >> >> Very good start! >> >>> I have no problem with a 'load' taking for ever, I know I am on the >>> other side of the ocean. But please change the cursor to a 'wait' >>> cursor while doing the load. It takes a loooooooong time before the >>> first progress bar shows, I almost panicked. And now a progress bar >>> just dissapeared, but there is still nothing I can do. The 'wait' >>> cursor would go a long way in easing my mind. And it's probably just >>> one line of code ... >> >> >> Yeah, this is a well known problem. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Nov. 30, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Updated trunk image

by Henrik Sperre Johansen

On 30.11.2009 19:29, StÃ©phane Ducasse wrote: >> >>>>> Collections >>>>> ----------- >>>>> Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly. >>>>> >> Yes, it should be ported to Pharo, I see no reason of divergence there. >> > Yes and I like the fast in the sentence :) It's probably along the lines of what I did back in August for Pharo, using the array primitives directly, instead of copying the elements one by one. Cheers, Henry

Nov. 30, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Updated trunk image

by StÃ©phane Ducasse

>>>> Menu Bar >>>> -------- >>>> Squeak now has a standard menu bar to make it easier to discover its contents for new users, replacing the World menu as the prime source for launching tools and other activities. >>>> >>>> Compiler >>>> -------- >>>> Support for literal ByteArray syntax has been added. Byte arrays can now be written as #[1 2 3 "..."] instead of #(1 2 3) asByteArray avoiding the need for conversion and a more compact default representation. >> we got that since long time ago >> > > Yes, I picked the method from Pharo :) :) I really wonder what would be squeak if you would not push it ;-D > >>>> Numbers >>>> ------- >>>> Some prime related changed: Integer>>isPrime is now a deterministic test, Integer>>isProbablyPrime a probabilistic variant. >> I think that andres changes were introduced. But apparently not. >> I will do that. Strange >> > > I think Leventes just picked Andres change... This is strange because I thought I integrated that. I will redo it. > >>>> Intger>>highBit and Integer>>lowBit have been sped up significantly. >> This is in >> > > Yes, though I cached 8bits in trunk instead of 4bits in Pharo and > initila mantis report. This is strange because I check the code and it looked similar. I will recheck later. > >> >>>> >>>> CRLF Handling >>>> ------------- >>>> CR and LF are now treated interchangeably in rendering. Both cause a line break and both are not displayed. Various line related methods have been updated to deal with both CR and LF. >> >> I imagine that this were fixes of nicolas >> > > Only the line splitting stuff is in Pharo (it was started in Pharo). > I did not port the transparent displaying of line feeds to Pharo yet. > Are you interested ? what is it? > >>>> Collections >>>> ----------- >>>> Dictionary is no longer a subclass of Set. HashedCollection is the new superclass for both Set and Dictionary. Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly. >> This is cool...... >> We definitively should look at that. >> > > Yes, it should be ported to Pharo, I see no reason of divergence there. Yes and I like the fast in the sentence :)

Nov. 30, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Updated trunk image

by StÃ©phane Ducasse

>> >> > > In trunk, Array still print #( ) if literal or {} if non literal. > The difference with Pharo is that anArray() form has been abandonned. > In Pharo, {} or anArray() is triggered by #isSelfEvaulating. ok I see. Lot of "features" from simple changes :) >>>> Dictionary>>keys return an array instead of a set. >> Nicolas does this bring some speed up, lukas thought so. >> > > Yes, the two advantages: > - speed up > - uniform behavior keys - values > > The drawback: > - a few packages will require a #asSet here and there (keys asSet) (I > estimate about 5% of senders) Ok we should integrate this one. >>>> > > Yes, it was proposed first in Pharo and is in already Pharo. > > Nicolas Thanks nicolas.

Nov. 30, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Updated trunk image

by Nicolas Cellier

2009/11/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Menu Bar >>> -------- >>> Squeak now has a standard menu bar to make it easier to discover its contents for new users, replacing the World menu as the prime source for launching tools and other activities. >>> >>> Compiler >>> -------- >>> Support for literal ByteArray syntax has been added. Byte arrays can now be written as #[1 2 3 "..."] instead of #(1 2 3) asByteArray Â avoiding the need for conversion and a more compact default representation. > we got that since long time ago > Yes, I picked the method from Pharo :) >>> Numbers >>> ------- >>> Some prime related changed: Integer>>isPrime is now a deterministic test, Integer>>isProbablyPrime a probabilistic variant. > I think that andres changes were introduced. But apparently not. > I will do that. Strange > I think Leventes just picked Andres change... >>> Intger>>highBit and Integer>>lowBit have been sped up significantly. > This is in > Yes, though I cached 8bits in trunk instead of 4bits in Pharo and initila mantis report. > >>> >>> CRLF Handling >>> ------------- >>> CR and LF are now treated interchangeably in rendering. Both cause a line break and both are not displayed. Various line related methods have been updated to deal with both CR and LF. > > I imagine that this were fixes of nicolas > Only the line splitting stuff is in Pharo (it was started in Pharo). I did not port the transparent displaying of line feeds to Pharo yet. Are you interested ? >>> Collections >>> ----------- >>> Dictionary is no longer a subclass of Set. HashedCollection is the new superclass for both Set and Dictionary. Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly. > This is cool...... > We definitively should look at that. > Yes, it should be ported to Pharo, I see no reason of divergence there. Nicolas > Stef > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 30, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Updated trunk image

by Nicolas Cellier

2009/11/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi > > I checked a bit > >>> ------ >>> Support for isolation layers has been retired. > > I imagine that this is the stuff related to project having their own changeset. > This is something that we are slowly removing and should go away with Project removal. > >>> Collections >>> ----------- >>> Several improvements have been added to Collections. Sets have become faster, > > >>> Arrays now print in brace form by default, > Now > Â Â Â Â {10@10 . Browser new} -> {10@10. aBrowser} > but this is nice not to have #(1 2) > but now I'm confused because after an update when I type #(1 2 3) I get #(1 2 3). > In trunk, Array still print #( ) if literal or {} if non literal. The difference with Pharo is that anArray() form has been abandonned. In Pharo, {} or anArray() is triggered by #isSelfEvaulating. > >>> Dictionary>>keys return an array instead of a set. > Nicolas does this bring some speed up, lukas thought so. > Yes, the two advantages: - speed up - uniform behavior keys - values The drawback: - a few packages will require a #asSet here and there (keys asSet) (I estimate about 5% of senders) > > >>> Monticello >>> ---------- >>> Various load-order issues have been fixed within Monticello, making loading of packages more robust. Monticello and PackageInfo have been sped up in several areas making browsing of large repositories significantly faster. > > I think that we should have most of them. We should probably check. > > >>> Faster UTF-8 Conversions >>> ------------------------ >>> Generalize trick from ByteString>>#squeakToUtf8 to every converter using class instance variables. Dramatically improves performance of file operations. > > Nicolas is it related to your FasterLatin1Conversion? Yes, it was proposed first in Pharo and is in already Pharo. Nicolas > > > >>> >>> >>> Shout >>> ----- >>> Shout (Syntax Hightlighting As You Type) has been added to this image. As with all new additions, it can be easily unloaded for people wanting smaller images. > > Probably worth to look at that. > >>> ToolBuilder conversion >>> ---------------------- >>> All the tools have been given a make-over, removing pretty much all of the interface construction code and replacing it by ToolBuilder specs. This removes a huge amount of dependencies between the tools and particular UI frameworks, and puts all the UIs on equal footing (there were several tools that were either not all or only partially supported in MVC before). > > Nice we should have a look at that. > > >>> New Text Editors >>> ---------------- >>> A complete new set of text editors (Editor, TextEditor and SmalltalkEditor) are available. They replace TextMorphEditor and break one of the last hard links between Morphic and MVC. With the new editors it will finally become possible to have Morphic be self-contained without the need to rely on portions of MVC. > > Juan told me that it will send us Â a package with the latest code integrated in squeak. > > > >>> Morphic Text Improvements >>> ------------------------- >>> Morphic has now regular blinking insertion point cursors instead of the (virtually invisible) static cursor previously. > We should have already this one > >>> In addition, various problems with mixing fonts and the heights of text have been fixed. > Would be nice if some font hackers would have a look > > >>> Beautiful, Anti-Aliased Fonts >>> ----------------------------- >>> We have a new set of beautiful anti-aliased Deja Vu bitmap fonts in this image. The default sizes include 7pt (for handheld devices), 9pt (generic text, list and menu fonts) as well as 12pt (window and title fonts): >>> Â Â Â Deja Vu 7pt: Regular, Bold, Italics >>> Â Â Â Deja Vu 9pt: Regular, Bold, Italics >>> Â Â Â Deja Vu 12pt: Regular, Bold, Italics > > We have them :) > Lukas will send a nice script. > > >>> >>> Russian Language Support >>> ------------------------ >>> To input text in Russian language, install a font supporting the Cyrillic alphabet, then switch the locale accordingly: >>> >>> Â Â Â TTFileDescription installFamilyNamed: 'Arial'. >>> Â Â Â Locale switchToID: (LocaleID isoLanguage: 'ru'). > > worth to have a look but a russian guy > > >>> This will enable Russian text input, display and processing. >>> >>> Improved Truetype Support >>> ------------------------- >>> The new TTFileDescription works just like TTFontDescription but operates on the files directly on disk. This helps greatly to support the m17n efforts since we no longer load all the fonts into memory. To use the available fonts on your platform, select some text, hit Cmd-k (Alt-k) and select "More (non-portable) fonts". > Do not the status of this one. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 30, 2009