- Pharo-dev - lists.pharo.org

Re: [Pharo-project] VM , modules, packages and plugins

by Igor Stasenko

On 28 June 2012 09:26, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 28/06/2012 00:48, Igor Stasenko a Ã©crit : > >> Seeing another thread about "is XYZ plugin there or not" or "what may >> cause prim fail" >> i REALLY suggest that we should stop and think.. >> This plugin's usage logic is inherently flawed.. (or i would say outdated) >> >> What i would like to see one day is when i installing new code into >> image, it pops up a message: >> "Your VM missing an XYZ plugin for running this cool code, would you >> like to download and install it? Yes No " >> >> In case of Pharo, we should really start thinking about delivering >> quality grade solutions, not something >> which might work if you properly jump 2 times and whistle 7 times >> while faced North"... >> >> Look at what the practices which become common today in modern >> browsers, and OSes - they updating themselves without a notice >> and just asking you to restart it time to time. Why we cannot do the same? >> > > What about using something existing, user-level (for Unix/linux and OSX > guys) such as 0install ? I'm using it for part of my desktop and it does the > update/search dependencies/compile if needed. I don't think making Pharo > plugins and VM available in the 0install system would be hard. > > http://0install.net/ > > (and it would work in allmost as many platform as Pharo does). > > It would only require some space to host the feeds and the files. > That's not a problem nowadays :) Yes, this project is interesting. > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Best regards, Igor Stasenko.

June 28, 2012

Re: [Pharo-project] Encodings, Charsets, converters... streams?

by Fernando Olivero

Cant we throw them all? And later add one by one when (if at all...) needed? Fernando On Wed, Jun 27, 2012 at 5:34 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I've spent 3 hours on trying to understand deeply the Multilingual mess, but I'm dying in the process... Â It mixes environments with charsets... Some charsets and converters are for really old OS versions... Sometimes it uses unicode, some times not... argggdsdsa > > On Wed, Jun 27, 2012 at 5:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > ok but how can we build a concrete roadmap. > What are the steps that we can take and perform one by one. > > Stef > > On Jun 27, 2012, at 3:11 PM, Henrik Sperre Johansen wrote: > >> On 25.06.2012 18<tel:25.06.2012%2018>:06, Denis Kudriashov wrote: >>> Hello. >>> >>> What is responsibility of environments (russian, japanese) classes. >>> Why its needed? Why converter classes not enough? >>> >>> For example, I can write russian text at workspace without setting any specific russian environment. I only need specific fonts for this. >>> >> Novadays, they can be used to read number/date printing policies, decide which translation package to use, etc. Basically what you'd expect from an OS locale, but more limited in capabilities. >> >> The part linked to charsets and encodings seem to me an anachronism from when the OS's used different encodings based on the selected environment though. (so files would be read and written automatically Â with the correct (non-unicode) encoding, and potentially displayed using a different bitmap font through selection using leadingChar) >> >>> 2012/6/25 Guillermo Polito <guillermopolito(a)gmail.com<mailto:guillermopolito@gmail.com>> >>> Hi guys, >>> >>> I'm trying to understand the Multilingual packages to get things a bit more reorganized. This way we can start to have a simpler and understandable kernel. So, >>> >>> - We have all environments(greek, chinese, japanese, korean, russian...) in the same package. Â Each environment has it's associated charset, and text converter, which are in different packages. Â Also, each text converter has a table of conversions between unicode and the encoding. But all converters are together, and all charsets are together. >>> >>> What about putting related things together? I mean, japanese converter with japanese environment with japanese charset in one package. Same with russian, korean, chinese... Â Does it make sense? Â This way we should be able to unload one of them if we do not really need it. >>> >> >>> - MultiByteFileStream and MultiByteBinaryOrTextStream are inside Multilingual-TextConversion? Â Even, they do the same on top of a file or a memory stream of bytes (or they say so in the comment :^D )... >>> >>> What about merging them? using a decorator? They have a lot in common... :/ Â Put them in a different package? >> They are not neatly composed. >> Trying to merge them so the methods work with a file and bytearray/string backend equivalently would probably only make things even worse. >> Using a decorator would be hard, since the MultiByteFileStream method implementations use alot of its inherited behaviour. >> >> As for putting them in a different package, sure you can peddle crap around all you want, but that doesn't make it stink any less. >>> >>> - Just curious. ImmPlugin is working or shipped with vms? Not for macos, because there is no macos implementation. Then, the class comment says: >>> >>> "On Windows, the plugin is not provided in the shipped VM's, and its current whereabouts are uncertain. >>> >>> On Unix, the only implemented behaviour is setting the position when over-the-spot precomposition of characters is the current mode. >>> >>> In the VM, the mode is chosen to the first available valid mode returned by the X Server, so whether this is actually relevant at all depends on the X Server." >>> >>> So, does someone use it and see value on keeping it? >> >> Sure, there is value in neatly integrating OS input methods for composed characters. >> >> Whether that belongs in a plugin of it's own, and whether what the plugin currently offers justifies its existence, is a different question, which I guess the removal was the answer to. :) >> >> To find any potential actual users, I guess you'd have to find a pharo app localized to the eastern hemisphere and have it ask their linux users if they appreciate it/if it works. >> That, or a developer from the same area who codes in his native language (which will be hard I think, given arbitrary tool constraints wrt message names etc.) >> >> Cheers, >> Henry > > >

June 28, 2012

Re: [Pharo-project] Do the VM's used on Jenkins include the SSL plugin ?

by Sven Van Caekenberghe

On 28 Jun 2012, at 00:32, Igor Stasenko wrote: > So, in case of ssl plugin you can clearly tell that if that prim > failed, you know that there's something wrong with plugin, i.e. it > fails to initialize or not exists: so even putting more informal > message "there seem to be problem with SSL plugin (missing? no SSL > library installed on your system? ) > will clarify a lot and prevent from wasting our time explaining why > that prim might fail or which VM has SSL and which might not. === Name: Zodiac-Core-SvenVanCaekenberghe.18 Author: SvenVanCaekenberghe Time: 28 June 2012, 10:04:19.612 am UUID: dca580f0-4d95-4d92-980c-1ebe622485d5 Ancestors: Zodiac-Core-SvenVanCaekenberghe.17 added ZdcPluginMissing exception to provided a more human friendly message when ZdcPluginSSLSession cannot be initialized (which is most probably due to a missing SSL/TLS plugin) === Now, ZdcPluginSSLSession>>initialize "Initialize the receiver" [ handle := self primitiveSSLCreate ] on: PrimitiveFailed do: [ :exception | "Give a more human friendly error message" ZdcPluginMissing signal ] with ZdcPluginMissing new printString. 'ZdcPluginMissing: SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?)' Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

June 28, 2012

Re: [Pharo-project] Google Code labels/templates

by Marcus Denker

On Jun 26, 2012, at 8:49 PM, Sean P. DeNigris wrote: > Someone had suggested to remove the "Pharo 1.4 Enhancement" template, since > we're not accepting any. That makes sense. > > Also, the Nautilus template labels the issue "Nautilus", but the label in > the list is "Type-Nautilus". Which brings me to my next question... > > The other Types are Bug, Enhancement, Cleanup, Feature [1]. Nautilus and > Jenkins [2] really don't fit into this framework. Maybe because there will > be many fewer issues, we don't need the level of granularity of [1] for [2]. > But when we get close to a release, it'd be nice to know that there is 1 > Nautilus bug and 10 Enhancements pending (i.e. probably only one critical > thing) vs. 11 Type-Nautilus. > > So, now that I said all that, it seems the most powerful/flexible approach > would be to leave the "nautilus" tag, remove the leading "Type-" from > "Type-[Jenkins|Spec|Seed]", and then to make templates for Jenkins/Spec/Seed > like the one for Nautilus. > > What do you think? honestly I don't care... there is so much to do that I can't even think about details like this. Marcus -- Marcus Denker -- http://marcusdenker.de

June 28, 2012

[Pharo-project] Tests Guard for 20167

by Pavel Krivanek

Tests Guard report for 20167: http://code.google.com/p/pharo/wiki/TestsGuard There are two big changes: Zodiac integration and working Windows host (GREAT!) We have got two new platform independent failures: * KernelTests.Chronology.DateTest.testAsSeconds * Zinc.Zodiac.ZnHTTPSTests.testWikimedia Several Zodiac related Linux and Windows failures: * Zodiac.Tests.ZdcSecureSocketStreamTests.testPlain * Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS * Zinc.Zodiac.ZnHTTPSTests.testGForceInria * Zinc.Zodiac.ZnHTTPSTests.testGmailEncrypted * Zinc.Zodiac.ZnHTTPSTests.testGoogleEncrypted * Zinc.Zodiac.ZnHTTPSTests.testPayPal * Zinc.Zodiac.ZnHTTPSTests.testRequestResponse * Zinc.Zodiac.ZnHTTPSTests.testTransfers * Zinc.Zodiac.ZnHTTPSTests.testTransfersSingleClient ...and several Windows specific failures: * CompressionTests.Archive.ZipArchiveTest.testCreateWithRelativeNames * FileSystem.Tests.Disk.DiskFileSystemTest.testDefaultWorkingDirectory * FileSystem.Tests.Disk.DiskFileSystemTest.testReferenceTo * FileSystem.Tests.Memory.MemoryFileSystemTest.testReferenceTo * NetworkTests.Kernel.SocketStreamTest.testUpToAfterCloseSignaling * NetworkTests.Kernel.SocketStreamTest.testUpToAllAfterCloseSignaling * NetworkTests.Url.UrlTest.testRoundTripFILE * Tests.Monticello.MCDataStreamTest.testFileNamed * Tests.Monticello.MCDataStreamTest.testReadOnlyFileNamed No test was made green. Cheers, -- Pavel

June 28, 2012

[Pharo-project] [update 1.4] #14446

by Marcus Denker

14446 ----- Issue 6189: [BUG]: Port to Pharo 1.4 - stdin hangs until EOF http://code.google.com/p/pharo/issues/detail?id=6189 Issue 6143: MIME decoding and Unicode not working http://code.google.com/p/pharo/issues/detail?id=6143 -- Marcus Denker -- http://marcusdenker.de

June 28, 2012

Re: [Pharo-project] Pharo 1.4 and Zodiac

by Henrik Sperre Johansen

On 27.06.2012 15:59, Henrik Sperre Johansen wrote: > On 27.06.2012 15:54, Sean P. DeNigris wrote: >> Dario Trussardi wrote >>> i work with Pharo1.4 Latest update: #14445 on MacBook. >>> >>> I'm interested to do TLS with Zodiac. >>> >> Funny, literally 5 minutes ago I was thinking maybe Zodiac should be >> included in 1.4... >> >> -- >> View this message in context: >> http://forum.world.st/Pharo-1-4-and-Zodiac-tp4636907p4636911.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > Are Windows/Linux versions of the plugin supposed to be automatically > built? > I seem to be getting the same primitive failures with the Cog-win.zip > from the pharo site... > > Cheers, > Henry I'm not saying I don't think "plugin not there" messages couldn't be clearer, or that I might like to be informed that a plugin relies on 3rd party libs which aren't available But when code with no fallback path to the plugin primitives is included in a released image, I would at least expect that plugin to be included in/with provided VM's on all platforms. Cheers, Henry

June 28, 2012

Re: [Pharo-project] Pharo 1.4 and Zodiac

by Marcus Denker

On Jun 28, 2012, at 9:20 AM, Henrik Sperre Johansen wrote: > On 27.06.2012 20:37, Igor Stasenko wrote: >> On 27 June 2012 16:38, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >>> On 27 Jun 2012, at 16:21, Henrik Sperre Johansen wrote: >>> >>>> Well, there's for sure no SqueakSSL so's or dll's in the downloads. >>>> I assumed it might be set to build as internal, in which case it doesn't seem to be working as intended (at least on Windows) >>> It is there the latest Mac OS and Linux VM's, but indeed not in the Windows VM. >>> >> Right, we got SSL only for mac and linux. >> For windows, AFAIK someone told that it has never worked. I think if >> you search mailing list archive for "SSL and windows" you will find it >> quickly. > The compiled .dll Sven linked worked just fine, so *someone* must have gotten it working :) >> The work i did with bundling 3rd party libs with VMs actually opens a >> good opportunity to fix that in future >> (we could DL/compile windows version of OpenSSL library and then >> corresponding plugin).. >> but that is something which has to be done in future. > Maybe it's just me, but I find having it available on all platforms is sort of a nice thing before including it in a release, at least when there's no non-plugin fallback code. I included it because I was told that all the VMs contain the plugin. Marcus -- Marcus Denker -- http://marcusdenker.de

June 28, 2012

Re: [Pharo-project] Pharo 1.4 and Zodiac

by Marcus Denker

On Jun 28, 2012, at 9:20 AM, Henrik Sperre Johansen wrote: > On 27.06.2012 20:37, Igor Stasenko wrote: >> On 27 June 2012 16:38, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >>> On 27 Jun 2012, at 16:21, Henrik Sperre Johansen wrote: >>> >>>> Well, there's for sure no SqueakSSL so's or dll's in the downloads. >>>> I assumed it might be set to build as internal, in which case it doesn't seem to be working as intended (at least on Windows) >>> It is there the latest Mac OS and Linux VM's, but indeed not in the Windows VM. >>> >> Right, we got SSL only for mac and linux. >> For windows, AFAIK someone told that it has never worked. I think if >> you search mailing list archive for "SSL and windows" you will find it >> quickly. > The compiled .dll Sven linked worked just fine, so *someone* must have gotten it working :) >> The work i did with bundling 3rd party libs with VMs actually opens a >> good opportunity to fix that in future >> (we could DL/compile windows version of OpenSSL library and then >> corresponding plugin).. >> but that is something which has to be done in future. > Maybe it's just me, but I find having it available on all platforms is sort of a nice thing before including it in a release, at least when there's no non-plugin fallback code. I included it because I was told that all the VMs contain the plugin. Marcus -- Marcus Denker -- http://marcusdenker.de

June 28, 2012

Re: [Pharo-project] VM , modules, packages and plugins

by Goubier Thierry

Le 28/06/2012 00:48, Igor Stasenko a Ã©crit : > Seeing another thread about "is XYZ plugin there or not" or "what may > cause prim fail" > i REALLY suggest that we should stop and think.. > This plugin's usage logic is inherently flawed.. (or i would say outdated) > > What i would like to see one day is when i installing new code into > image, it pops up a message: > "Your VM missing an XYZ plugin for running this cool code, would you > like to download and install it? Yes No " > > In case of Pharo, we should really start thinking about delivering > quality grade solutions, not something > which might work if you properly jump 2 times and whistle 7 times > while faced North"... > > Look at what the practices which become common today in modern > browsers, and OSes - they updating themselves without a notice > and just asking you to restart it time to time. Why we cannot do the same? > What about using something existing, user-level (for Unix/linux and OSX guys) such as 0install ? I'm using it for part of my desktop and it does the update/search dependencies/compile if needed. I don't think making Pharo plugins and VM available in the 0install system would be hard. http://0install.net/ (and it would work in allmost as many platform as Pharo does). It would only require some space to host the feeds and the files. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 28, 2012