[Pharo-dev] Distributing File Resources
Hi everyone, I've been trying to move things over to Pharo and may be a bit more active on the list. Part of that is trying to use smalltalkhub to manage my code. Since I do a lot of visual work, I tend to have a lot of images (and sounds) to manage. I'd like to be able to distribute them easily but I can't seem to find a way to upload them to a shared directory. In Squeak, there was this idea of .SAR files for distributing files. Is there a good solution for this outside of the Seaside approach of embedding the file information in class methods. I'm talking about hundreds of files and multiple MBs here, rather than one or two small files. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
[Pharo-dev] Win32 Console support
Esteban wrote why those methods names? For a quick start I followed the API names. It's easier when one wraps non-OO native code. Thats why I mumbled something about cleaning code... ;) Bye T.
Re: [Pharo-dev] TalkFFI versions 1.3 and 1.4
Guys, just FYI, in Gofer it smalltalkhubUser: 'CipT' project: 'TalkFFI'; configurationOf: 'TalkFFI'; load you'll find a new version of the configuration of TalkFFI: - version 1.3.1 works without any changes Gofer it smalltalkhubUser: 'CipT' project: 'TalkFFI'; configurationOf: 'TalkFFI'; loadVersion: '1.3.1' - stable version points to 1.3.1 on pharo2 Gofer it smalltalkhubUser: 'CipT' project: 'TalkFFI'; configurationOf: 'TalkFFI'; loadVersion: #'stable' Regarding version 1.4, I don't know so far :). Enjoy, Guille On Sun, Sep 1, 2013 at 12:47 PM, Guillermo Polito guillermopol...@gmail.com wrote: Hi Ciprian, In the last weeks we were playing a bit with TalkFFI for dbxtalk. After a while we got a working version but we found some stuff we'd like to fix. In version 1.3 CLExternalLibraryWrapper classuniqueInstance is wrongly defined. This is already fixed in talkffi 1.4. However, version 1.4 includes some other changes that make the VM just crash, :). What do you think about making a 1.3.1 version with the minor fix for the unique instance so we can move on without overrides? Of course I'm happy to provide the code (given the credentials to commit :)). TIA, Guille
Re: [Pharo-dev] TalkFFI versions 1.3 and 1.4
Thanks Guillermo for your effort On Tue, Sep 3, 2013 at 9:41 AM, Guillermo Polito guillermopol...@gmail.comwrote: Guys, just FYI, in Gofer it smalltalkhubUser: 'CipT' project: 'TalkFFI'; configurationOf: 'TalkFFI'; load you'll find a new version of the configuration of TalkFFI: - version 1.3.1 works without any changes Gofer it smalltalkhubUser: 'CipT' project: 'TalkFFI'; configurationOf: 'TalkFFI'; loadVersion: '1.3.1' - stable version points to 1.3.1 on pharo2 Gofer it smalltalkhubUser: 'CipT' project: 'TalkFFI'; configurationOf: 'TalkFFI'; loadVersion: #'stable' Regarding version 1.4, I don't know so far :). For 1.4 i'll find some time to spend on it in the near future Cheers, Ciprian Enjoy, Guille On Sun, Sep 1, 2013 at 12:47 PM, Guillermo Polito guillermopol...@gmail.com wrote: Hi Ciprian, In the last weeks we were playing a bit with TalkFFI for dbxtalk. After a while we got a working version but we found some stuff we'd like to fix. In version 1.3 CLExternalLibraryWrapper classuniqueInstance is wrongly defined. This is already fixed in talkffi 1.4. However, version 1.4 includes some other changes that make the VM just crash, :). What do you think about making a 1.3.1 version with the minor fix for the unique instance so we can move on without overrides? Of course I'm happy to provide the code (given the credentials to commit :)). TIA, Guille -- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodo...@gmail.com www.teodorov.ro
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 03/09/2013 10:28, Henrik Johansen a écrit : On Sep 2, 2013, at 4:41 , Goubier Thierry thierry.goub...@cea.fr wrote: Le 02/09/2013 16:07, Stéphane Ducasse a écrit : what we could do is to not deprecate now the methods? Then we can deprecate them when we release 3.0 When starting pharo4? That would be perfect :) I just noticed that Smalltalk os exist in 1.4 and 2.0. So my code should work on an old image, isn't it? It would also work on 2.0 and 1.4, no? (or something like (Smalltalk respondsTo: #os) ifTrue: [Smalltalk os name]) When was Smalltalkos introduced ? Thierry 3.5 years ago ;) http://forum.world.st/Worth-reading-discussion-on-Smalltalk-vs-SmalltalkImage-td1576291.html#a1576588 It's been included since Pharo 1.1/Squeak 4.1, so it's a reasonable default path. Though, better use Smalltalk os platformName (which should work in all versions since the above mentioned), writing a test for whether #name is the correct method to use ala 3.0 would be an interesting exercise since it's also implemented for older returns of Smalltalk os, but with a different meaning. *cough* find a better selector for 3.0? *cough* I think OSPlatform is one of those packages which tries to work on Squeak 3.6 and up, and in that case you still need more fallbacks. Cheers, Henry Thanks Henry for the info. However, I'm sure platformName (and platformSubtype) will be deprecated in Pharo sooner or later... leaving us with another deprecation. At least the deprecation warning seems to be pointing to that. At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? 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
Re: [Pharo-dev] Win32 Console support
On 3 September 2013 00:14, Esteban Lorenzano esteba...@gmail.com wrote: is very nice :) but... a bit of criticism (and probably ignorant criticism :P) why those methods names? sets, gets. colored, colorgreen... instead pharoish names? I think because most of windows API functions named like that. Which sometimes better, to keep connection with original API.. Not sure about color names though :) Cheers, Esteban On Sep 2, 2013, at 11:34 PM, Torsten Bergmann asta...@gmx.de wrote: I played with NativeBoost and the Windows API again this evening with the result to be able to open a native Win32 console window, influence title and colors and write to it from Pharo. This can be useful for coral and stdout support on Windows too. Attached is a screenshot. Cleaned up code will follow soon. Thx T. winconsole.png -- Best regards, Igor Stasenko.
[Pharo-dev] SmallInteger infamous bug is back in town
... most probably due to errors in the integration process. I spotted it in last vm :( sadly, I do not have time to tackle it before ESUG, so... until I fix it, please don't use the latest vm. Instead, take one of the olders if you need to download a new one. I'm sorry for the inconvenience :( Esteban
[Pharo-dev] [update 3.0] #30365
30365 - 11444 Improving MiniKernel https://pharo.fogbugz.com/f/cases/11444 11507 NautilusAbstractUI should be accept different classifiers https://pharo.fogbugz.com/f/cases/11507 (This was alreay in, at least I did not see any changes when merging) 11148 shouldnt:raise: should not be used https://pharo.fogbugz.com/f/cases/11148 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/ToolsTest-MarcusDenker.denker.59.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.620.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.66.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SmartSuggestions-MarcusDenker.106.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-Tests-MarcusDenker.25.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-Core-MarcusDenker.97.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Tests-Kernel-MarcusDenker.54.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Changes-MarcusDenker.31.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-MarcusDenker.63.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Tests-MarcusDenker.116.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenker.203.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NetworkTests-MarcusDenker.86.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Multilingual-TextConversion-MarcusDenker.60.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Multilingual-Tests-MarcusDenker.31.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Multilingual-Languages-MarcusDenker.36.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Multilingual-OtherLanguages-MarcusDenker.2.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Multilingual-Encodings-MarcusDenker.41.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/MorphicTests-MarcusDenker.76.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-Resources-Tests-MarcusDenker.11.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-Core-MarcusDenker.157.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-MarcusDenker.559.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1590.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/HelpSystem-Tests-MarcusDenker.24.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Tests-MarcusDenker.41.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Gofer-Tests-MarcusDenker.159.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FuelTests-MarcusDenker.335.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Tests-Core-MarcusDenker.60.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CompilerTests-MarcusDenker.177.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-MarcusDenker.629.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-MarcusDenker.278.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/ClassOrganizer-Tests-MarcusDenker.5.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Announcements-Tests-Core-MarcusDenker.16.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Interpreter-Test-MarcusDenker.86.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-MarcusDenker.191.diff signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Distributing File Resources
yes that would be great to have indeed. On Tuesday, September 3, 2013, J.F. Rick s...@je77.com wrote: Hi everyone, I've been trying to move things over to Pharo and may be a bit more active on the list. Part of that is trying to use smalltalkhub to manage my code. Since I do a lot of visual work, I tend to have a lot of images (and sounds) to manage. I'd like to be able to distribute them easily but I can't seem to find a way to upload them to a shared directory. In Squeak, there was this idea of .SAR files for distributing files. Is there a good solution for this outside of the Seaside approach of embedding the file information in class methods. I'm talking about hundreds of files and multiple MBs here, rather than one or two small files. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
Re: [Pharo-dev] Distributing File Resources
What I would like to have is - A way to save files per package in the image in a virtual file system - Monticello support to save that virtual file system as part of the .mcz We could clean up *a lot* of methods in the image and even save memory: right now the save Base64 encoded strings in methods means that we have the data two times: the string literal and the object created from it. (and the source on disk). On Sep 3, 2013, at 11:23 AM, p...@highoctane.be wrote: yes that would be great to have indeed. On Tuesday, September 3, 2013, J.F. Rick s...@je77.com wrote: Hi everyone, I've been trying to move things over to Pharo and may be a bit more active on the list. Part of that is trying to use smalltalkhub to manage my code. Since I do a lot of visual work, I tend to have a lot of images (and sounds) to manage. I'd like to be able to distribute them easily but I can't seem to find a way to upload them to a shared directory. In Squeak, there was this idea of .SAR files for distributing files. Is there a good solution for this outside of the Seaside approach of embedding the file information in class methods. I'm talking about hundreds of files and multiple MBs here, rather than one or two small files. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Distributing File Resources
Managing resources is not well handled and it would be great to have some propositions. Hi everyone, Welcome!! I've been trying to move things over to Pharo and may be a bit more active on the list. Part of that is trying to use smalltalkhub to manage my code. Since I do a lot of visual work, I tend to have a lot of images (and sounds) to manage. I'd like to be able to distribute them easily but I can't seem to find a way to upload them to a shared directory. In Squeak, there was this idea of .SAR files for distributing files. Is there a good solution for this outside of the Seaside approach of embedding the file information in class methods. I'm talking about hundreds of files and multiple MBs here, rather than one or two small files. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] SmallInteger infamous bug is back in town
can the 'latest version' not be retracted ? On 03 Sep 2013, at 11:07, Esteban Lorenzano esteba...@gmail.com wrote: ... most probably due to errors in the integration process. I spotted it in last vm :( sadly, I do not have time to tackle it before ESUG, so... until I fix it, please don't use the latest vm. Instead, take one of the olders if you need to download a new one. I'm sorry for the inconvenience :( Esteban
Re: [Pharo-dev] Distributing File Resources
I'm surprised this doesn't exist yet. It seems like it would be a natural thing to be part of Monticello. Cheers, Jeff On Tue, Sep 3, 2013 at 11:29 AM, Marcus Denker marcus.den...@inria.frwrote: What I would like to have is - A way to save files per package in the image in a virtual file system - Monticello support to save that virtual file system as part of the .mcz We could clean up *a lot* of methods in the image and even save memory: right now the save Base64 encoded strings in methods means that we have the data two times: the string literal and the object created from it. (and the source on disk). On Sep 3, 2013, at 11:23 AM, p...@highoctane.be wrote: yes that would be great to have indeed. On Tuesday, September 3, 2013, J.F. Rick s...@je77.com wrote: Hi everyone, I've been trying to move things over to Pharo and may be a bit more active on the list. Part of that is trying to use smalltalkhub to manage my code. Since I do a lot of visual work, I tend to have a lot of images (and sounds) to manage. I'd like to be able to distribute them easily but I can't seem to find a way to upload them to a shared directory. In Squeak, there was this idea of .SAR files for distributing files. Is there a good solution for this outside of the Seaside approach of embedding the file information in class methods. I'm talking about hundreds of files and multiple MBs here, rather than one or two small files. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] Distributing File Resources
Hi Jeff, Would you have an interest looking into this and prototyping a solution? Doru On Tue, Sep 3, 2013 at 12:44 PM, J.F. Rick s...@je77.com wrote: I'm surprised this doesn't exist yet. It seems like it would be a natural thing to be part of Monticello. Cheers, Jeff On Tue, Sep 3, 2013 at 11:29 AM, Marcus Denker marcus.den...@inria.frwrote: What I would like to have is - A way to save files per package in the image in a virtual file system - Monticello support to save that virtual file system as part of the .mcz We could clean up *a lot* of methods in the image and even save memory: right now the save Base64 encoded strings in methods means that we have the data two times: the string literal and the object created from it. (and the source on disk). On Sep 3, 2013, at 11:23 AM, p...@highoctane.be wrote: yes that would be great to have indeed. On Tuesday, September 3, 2013, J.F. Rick s...@je77.com wrote: Hi everyone, I've been trying to move things over to Pharo and may be a bit more active on the list. Part of that is trying to use smalltalkhub to manage my code. Since I do a lot of visual work, I tend to have a lot of images (and sounds) to manage. I'd like to be able to distribute them easily but I can't seem to find a way to upload them to a shared directory. In Squeak, there was this idea of .SAR files for distributing files. Is there a good solution for this outside of the Seaside approach of embedding the file information in class methods. I'm talking about hundreds of files and multiple MBs here, rather than one or two small files. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) Dave
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 03/09/2013 12:56, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Dave -- 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
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: Le 03/09/2013 12:56, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog. If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure). Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak. Dave Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Thanks! Dave Dave -- 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
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 03/09/2013 13:36, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: Le 03/09/2013 12:56, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog. If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure). Ok. Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak. Thanks. Thierry Dave Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- 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 -- 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
Re: [Pharo-dev] Distributing File Resources
I started an in-image filesystem which would add resources to each Class and Package. Of course this currently does not yet tackle the versioning part, but it could be built on top. In any case, my idea was that these resources can either live in the image or on the normal os filesystem. you can have a peek at it here: http://smalltalkhub.com/#!/~dh83/FileSystemST On 2013-09-03, at 07:48, Tudor Girba tu...@tudorgirba.com wrote: Hi Jeff, Would you have an interest looking into this and prototyping a solution? Doru On Tue, Sep 3, 2013 at 12:44 PM, J.F. Rick s...@je77.com wrote: I'm surprised this doesn't exist yet. It seems like it would be a natural thing to be part of Monticello. Cheers, Jeff On Tue, Sep 3, 2013 at 11:29 AM, Marcus Denker marcus.den...@inria.frwrote: What I would like to have is - A way to save files per package in the image in a virtual file system - Monticello support to save that virtual file system as part of the .mcz We could clean up *a lot* of methods in the image and even save memory: right now the save Base64 encoded strings in methods means that we have the data two times: the string literal and the object created from it. (and the source on disk). On Sep 3, 2013, at 11:23 AM, p...@highoctane.be wrote: yes that would be great to have indeed. On Tuesday, September 3, 2013, J.F. Rick s...@je77.com wrote: Hi everyone, I've been trying to move things over to Pharo and may be a bit more active on the list. Part of that is trying to use smalltalkhub to manage my code. Since I do a lot of visual work, I tend to have a lot of images (and sounds) to manage. I'd like to be able to distribute them easily but I can't seem to find a way to upload them to a shared directory. In Squeak, there was this idea of .SAR files for distributing files. Is there a good solution for this outside of the Seaside approach of embedding the file information in class methods. I'm talking about hundreds of files and multiple MBs here, rather than one or two small files. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- www.tudorgirba.com Every thing has its own flow signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
bah... I would just go for maintaining a fork of OSProcess with simple rewriters for these methods and backporting fixes from the main repository. I think all-in-one solutions only result in bad code.. On 2013-09-03, at 08:48, Goubier Thierry thierry.goub...@cea.fr wrote: Le 03/09/2013 13:36, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: Le 03/09/2013 12:56, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog. If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure). Ok. Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak. Thanks. Thierry Dave Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- 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 -- 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5... :) Thierry Le 03/09/2013 14:22, Camillo Bruni a écrit : bah... I would just go for maintaining a fork of OSProcess with simple rewriters for these methods and backporting fixes from the main repository. I think all-in-one solutions only result in bad code.. On 2013-09-03, at 08:48, Goubier Thierry thierry.goub...@cea.fr wrote: Le 03/09/2013 13:36, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: Le 03/09/2013 12:56, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 10:58:07AM +0200, Goubier Thierry wrote: At the same time, parts of OSProcess seems to not be working under Pharo2 anyway :( I don't even think I'm able to run the tests (locked up my 3.0 image it did). My last set of updates to OSProcess for Pharo were done in January 2013, and it worked at that time. Has something stopped working since then? I've been using OSProcess sucessfully on Pharo1.4 and 2.0 for quite a long time now; however, when trying to test if I did everything right on a 3.0 adaptation, running the tests ended up 1- uncovering more deprecated warnings with things that do not exist under Pharo2 (so that the Pharo2 solution is deprecated on Pharo3, and the Pharo3 solution does not exist in Pharo2... yuck. ensureDelete it is). 2- test failures due to missing Xcontrol plugin? (and permanent process error afterwards) so I scrapped that image and my implementation, will rewrite everything with a fresh new image. Can I give up on trying to run OSProcess tests? The tests require XDisplayControlPlugin in the VM in order to do many of the multi-process tests, because #forkSqueak is used to create cooperating VM processes for the tests. In addition, some OSProcess function will not work on Cog. If you can run the tests on an interpreter VM they should pass. If you can get XDisplayControlPlugin included in the VM, then I expect that most of the tests would pass (we would have to try it to be sure). Ok. Otherwise, yes, you can give up on running the tests. You may still find them useful as a source of examples and for running specific tests that do not require #forkSqueak. Thanks. Thierry Dave Looks like a version / implementation test would be the way to go. I'll write something which should work on 2.0 / 3.0, and failure protection to fallback for anything else. Is there a standard way to test for implementation/version on all Squeak and Pharo versions ? No. And as you can see from the examples in OSProcess, it is becoming increasingly difficult to cobble up a solution that works for an externally maintained package. If you can find a better solution, that would be great :) I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- 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 -- 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 -- 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
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : On Tue, Sep 03, 2013 at 01:15:01PM +0200, Goubier Thierry wrote: I'm attempting something. Is is OK if I save in the OSProcess squeaksource repository? Thierry Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): Thank you! I will check this when I get home this evening. Dave in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName
[Pharo-dev] [update 3.0] #30366
30366 - 11515 Rename protocols shortcut changed https://pharo.fogbugz.com/f/cases/11515 11450 Protocol rename duplication https://pharo.fogbugz.com/f/cases/11450 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-MarcusDenker.529.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/ClassOrganizer-Core-MarcusDenker.4.diff signature.asc Description: Message signed with OpenPGP using GPGMail
[Pharo-dev] Switching context(s) in browser while method is not-yet accepted
this is most annoying to me, that UI interrupts you in very strange manner and asks you to make a decision: - accept, or discard the method, or cancel the action. often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :) what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do. And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window). -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Distributing File Resources
I'll certainly create one to serve my own needs. I'll also think about how a more general purpose one might look. Ideally, it would just integrate with Monticello so that each package could contain its own resources. On the other hand, code is small and can easily be saved in each version whereas resources are quite large and could cause each saved thing to be huge. I'll keep people informed of where I get to. I'll also take a look at FileSystemST and see where that leads me. Cheers, Jeff On Tue, Sep 3, 2013 at 12:48 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi Jeff, Would you have an interest looking into this and prototyping a solution? Doru On Tue, Sep 3, 2013 at 12:44 PM, J.F. Rick s...@je77.com wrote: I'm surprised this doesn't exist yet. It seems like it would be a natural thing to be part of Monticello. Cheers, Jeff On Tue, Sep 3, 2013 at 11:29 AM, Marcus Denker marcus.den...@inria.frwrote: What I would like to have is - A way to save files per package in the image in a virtual file system - Monticello support to save that virtual file system as part of the .mcz We could clean up *a lot* of methods in the image and even save memory: right now the save Base64 encoded strings in methods means that we have the data two times: the string literal and the object created from it. (and the source on disk). On Sep 3, 2013, at 11:23 AM, p...@highoctane.be wrote: yes that would be great to have indeed. On Tuesday, September 3, 2013, J.F. Rick s...@je77.com wrote: Hi everyone, I've been trying to move things over to Pharo and may be a bit more active on the list. Part of that is trying to use smalltalkhub to manage my code. Since I do a lot of visual work, I tend to have a lot of images (and sounds) to manage. I'd like to be able to distribute them easily but I can't seem to find a way to upload them to a shared directory. In Squeak, there was this idea of .SAR files for distributing files. Is there a good solution for this outside of the Seaside approach of embedding the file information in class methods. I'm talking about hundreds of files and multiple MBs here, rather than one or two small files. Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- www.tudorgirba.com Every thing has its own flow -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
[Pharo-dev] I need update of ConfigurationOfZincHTTPComponents
Hi Jan, Hi Sven, in ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.51 (http://mc.stfx.eu/ZincHTTPComponents) there is following entry package: 'Zinc-SSO-OAuth2-Core' with: 'Zinc-SSO-OAuth2-Core-JanVanDeSandt.15'; which has an invalid reference to removed variable refreshToken could you please reference Name: Zinc-SSO-OAuth2-Core-JanVanDeSandt.16 instead or allow me to do this? regards Sabine -- View this message in context: http://forum.world.st/I-need-update-of-ConfigurationOfZincHTTPComponents-tp4706298.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] Sound on Ubuntu Problems
I'm using Pharo 2.0 on Ubuntu 13.10 and I can't seem to get sound working. Getting sound to work on Linux seems to be a common problem. While I've checked the archive for solutions, none of them work for me. I've investigated a bit and here's what I've found: Inside of the /usr/lib/pharo-vm directory, I see the following: vm-sound-ALSA.so vm-sound-null.so vm-sound-pulse.so (I added that based on an archive post that this would work) When I do pharo -vm-sound-null pharo.image, it works correctly. When I do pharo -vm-sound-ALSA pharo.image, it gives me an error that could not find module vm-sound-ALSA. When I do pharo-help, I find that the only sound driver available is vm-sound-null, though the others are clearly there in the directory. Is there anything I can do to make the VM acknowledge that the other files are there? Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] I need update of ConfigurationOfZincHTTPComponents
On 03 Sep 2013, at 16:33, Sabine Knöfel sabine.knoe...@gmail.com wrote: Hi Jan, Hi Sven, in ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.51 (http://mc.stfx.eu/ZincHTTPComponents) there is following entry package: 'Zinc-SSO-OAuth2-Core' with: 'Zinc-SSO-OAuth2-Core-JanVanDeSandt.15'; which has an invalid reference to removed variable refreshToken could you please reference Name: Zinc-SSO-OAuth2-Core-JanVanDeSandt.16 instead === Name: ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.52 Author: SvenVanCaekenberghe Time: 3 September 2013, 4:45:48.745714 pm UUID: 703372ae-f1b9-4c1a-add5-b0696a4375b1 Ancestors: ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.51 Quick patch to reference Zinc-SSO-OAuth2-Core-JanVanDeSandt.16 in current v 2.4.4 === Thanks, Sven or allow me to do this? regards Sabine -- View this message in context: http://forum.world.st/I-need-update-of-ConfigurationOfZincHTTPComponents-tp4706298.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
I agree but I want to offer something slightly different. Remove the accept button/ command altogether. Anything that is typed by the user is automatically accepted , if user changes his mind he should be able to use undo/redo . Preferably create a history tool (dont know if changes could help here, I know pharo users use this to recover lost changes) similar to ones found in Photoshop or 3d apps that the user can use to return back in time to any change he made without pressing undo continuously. It is annoyance and offers zero advantages as it is to the user. But I am curious to listening to other opinions as well on this. -- View this message in context: http://forum.world.st/Switching-context-s-in-browser-while-method-is-not-yet-accepted-tp4706294p4706306.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] I need update of ConfigurationOfZincHTTPComponents
Great. Thank you for the quick fix! Sabine On Tue, Sep 3, 2013 at 4:48 PM, Sven Van Caekenberghe-2 [via Smalltalk] ml-node+s1294792n4706299...@n4.nabble.com wrote: On 03 Sep 2013, at 16:33, Sabine Knöfel [hidden email]http://user/SendEmail.jtp?type=nodenode=4706299i=0 wrote: Hi Jan, Hi Sven, in ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.51 (http://mc.stfx.eu/ZincHTTPComponents) there is following entry package: 'Zinc-SSO-OAuth2-Core' with: 'Zinc-SSO-OAuth2-Core-JanVanDeSandt.15'; which has an invalid reference to removed variable refreshToken could you please reference Name: Zinc-SSO-OAuth2-Core-JanVanDeSandt.16 instead === Name: ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.52 Author: SvenVanCaekenberghe Time: 3 September 2013, 4:45:48.745714 pm UUID: 703372ae-f1b9-4c1a-add5-b0696a4375b1 Ancestors: ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.51 Quick patch to reference Zinc-SSO-OAuth2-Core-JanVanDeSandt.16 in current v 2.4.4 === Thanks, Sven or allow me to do this? regards Sabine -- View this message in context: http://forum.world.st/I-need-update-of-ConfigurationOfZincHTTPComponents-tp4706298.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- If you reply to this email, your message will be added to the discussion below: http://forum.world.st/I-need-update-of-ConfigurationOfZincHTTPComponents-tp4706298p4706299.html To unsubscribe from I need update of ConfigurationOfZincHTTPComponents, click herehttp://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4706298code=c2FiaW5lLmtub2VmZWxAZ21haWwuY29tfDQ3MDYyOTh8MTA0OTM5MTYx . NAMLhttp://forum.world.st/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://forum.world.st/I-need-update-of-ConfigurationOfZincHTTPComponents-tp4706298p4706300.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
kilon wrote: I agree but I want to offer something slightly different. Remove the accept button/ command altogether. Anything that is typed by the user is automatically accepted , if user changes his mind he should be able to use undo/redo . Preferably create a history tool (dont know if changes could help here, I know pharo users use this to recover lost changes) similar to ones found in Photoshop or 3d apps that the user can use to return back in time to any change he made without pressing undo continuously. It is annoyance and offers zero advantages as it is to the user. But I am curious to listening to other opinions as well on this. -- View this message in context: http://forum.world.st/Switching-context-s-in-browser-while-method-is-not-yet-accepted-tp4706294p4706306.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. That sounds dangerous, particularly if you are playing with internals of UI or other system parts. What if half way through an edit you need to leave the keyboard, and that ends up being a few hours or longer, and you don't remember where you were. regards -ben
Re: [Pharo-dev] OSProcess for Pharo3.0
On 2013-09-03, at 09:36, Goubier Thierry thierry.goub...@cea.fr wrote: And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5... exactly, and for each Pharo version there is a different branch of OSProcess. well, once you start working on git you see the advantages of branches ;) too bad that the monticello tools do not properly support this feature. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Win32 Console support
Hi. Interesting, what will happen if you run printing lines to console in loop and then stop console scrollbar by mouse? Will image hangs? 2013/9/3 Torsten Bergmann asta...@gmx.de I played with NativeBoost and the Windows API again this evening with the result to be able to open a native Win32 console window, influence title and colors and write to it from Pharo. This can be useful for coral and stdout support on Windows too. Attached is a screenshot. Cleaned up code will follow soon. Thx T.
[Pharo-dev] Win32 Console support
Denis wrote Hi. Interesting, what will happen if you run printing lines to console in loop and then stop console scrollbar by mouse? Will image hangs? Nothing spectacular - when I click the scrollbar (while output from ST loops) the output stops until I finish moving the scrollbar slider of the console window. When I release the mouse from the slider it will continue to write to console output. Image does not hang. Bye T.
Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
agreed we should change that since years. Some days we should stop and fix all the glitches that give us these hiccups. stef On Sep 3, 2013, at 3:07 PM, Igor Stasenko siguc...@gmail.com wrote: this is most annoying to me, that UI interrupts you in very strange manner and asks you to make a decision: - accept, or discard the method, or cancel the action. often, you are in the middle of typing new stuff and source code can be even not syntactically correct.. so, you have to discard or die :) what i think the solution could be is that browser should allow you to switch contexts at any moment without asking you anything.Instead it should remember your unsaved changes in special 'drafts' collection, which later you can get back on, when you finish what you wanted to do. And the only time when you want unaccepted edits to not get lost forever is when you closing a browser window.. (but of course, drafts can be stored globally somewhere, then it also not a big deal, since you can simply return to your draft in different window). -- Best regards, Igor Stasenko.
[Pharo-dev] specialSelectors
I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference.
Re: [Pharo-dev] Should Job use SystemAnnouncer?
Camillo wrote: in this case it is only the instance of Job which knows the status. Thread-safeness is not an issue since the progress bar is pure approximation. The problem is not approximation. Objects are not reentrant, getting the value out of a model while it is reorganizing its datastructure is likely to give interesting and difficult to reproduce results (dividing by 0, nil-pointer exceptions). that does not work properly and inaccurately reports long running jobs, for instance when running tests. Usually tests take far less than 1 ms, in which case this scheme works perfectly. However from time to time you have 1 test that runs for a couple of seconds. If you run 5000 tests you have to run quite a few tests to get that 1% update margin, so very often the UI does not correctly report the current status. That is not a solvable problem. A progress bar depends on a value increasing from min to max. The model is responsible for making reasonable steps. Anyway, this requires quite some changes in the current ProgressBarMorph, so any other improvement until then is welcome :) I've put together a new slice in the 30 Inbox with the combined changes. Where should I put a backport for 2.0?
Re: [Pharo-dev] Should Job use SystemAnnouncer?
On 2013-09-03, at 18:57, Stephan Eggermont step...@stack.nl wrote: Camillo wrote: in this case it is only the instance of Job which knows the status. Thread-safeness is not an issue since the progress bar is pure approximation. The problem is not approximation. Objects are not reentrant, getting the value out of a model while it is reorganizing its datastructure is likely to give interesting and difficult to reproduce results (dividing by 0, nil-pointer exceptions). that does not work properly and inaccurately reports long running jobs, for instance when running tests. Usually tests take far less than 1 ms, in which case this scheme works perfectly. However from time to time you have 1 test that runs for a couple of seconds. If you run 5000 tests you have to run quite a few tests to get that 1% update margin, so very often the UI does not correctly report the current status. That is not a solvable problem. A progress bar depends on a value increasing from min to max. The model is responsible for making reasonable steps. ok, different question, how do you solve this very use-case without polling? 1. run test 1 [1ms] . N. run test N [1ms] --- Progress Bar update limit reached after a) either N update calls b) N ms = next update will happen in a) N calls b) N ms --- N+1. run test N+1 [1000 ms] That means that the UI shows the wrong value (run test N) instead of the current progress value (run test N+1), which is not interesting. The model, in this case the test runner, properly informed the UI about every change, but the update limitations in the ProgressBarMorph cannot properly detect such a case. - either you update way to often = performance overhead - or you update not often enough = inaccurate progress indication when progress step times differ a lot There is simply no way you can properly solve this case without active polling. As for your doubts about thread-safeness: The model for the ProgressBar is the Job class. It is hence the only entry point for the PogressBar and thus can easily be made threadsafe. My use-case is simply that I want to see in which test-case the test runner hangs. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] specialSelectors
that would actually be interesting on how much you win by doing so, and if you could run this dynamically (for instance reintroduce the #class optimization if you never override it in the image)... On 2013-09-03, at 19:07, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] specialSelectors
Well, #class slot is not really available because the trick is hardcoded in the VM as well as == trick, so no lookup in specialSelectors (specailObjectsArray at: 24) is attempted for these 2. COG also optimize some arithmetic messages, comparisons, bit ops, and all is hardcoded in the VM, so better not playing with those indices. So I tried to just replace #blockCopy: 1 with #not 0, ran some tests but saw no significative speed up. Then I tried to run Kernel tests twice in a unmodified 3.0 image [(Smalltalk allClasses select: [:e | (e category beginsWith: 'KernelTests') and: [e inheritsFrom: TestCase]]) do: [:e | e suite run]] timeToRun. 113342 114337 Then optimized the mosttly sent message during tests : IRByteCodeGeneratorspecialSelectorsArray ^ #(#+ 1 #- 1 # 1 # 1 #= 1 #= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 nil 0 #assert: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) Recompiled all: IRBytecodeGenerator initializeSpecialSelectors. Smalltalk specialObjectsArray at: 24 put: IRBytecodeGenerator specialSelectorsArray. OpalCompiler recompileAll. Then tried the tests twice again: [(Smalltalk allClasses select: [:e | (e category beginsWith: 'KernelTests') and: [e inheritsFrom: TestCase]]) do: [:e | e suite run]] timeToRun. 84328 83974 So it seems like it's not just a space optimization but also a speed one, and I don't know why... It would be better if someone could repeat these results... Nicolas 2013/9/4 Camillo Bruni camillobr...@gmail.com that would actually be interesting on how much you win by doing so, and if you could run this dynamically (for instance reintroduce the #class optimization if you never override it in the image)... On 2013-09-03, at 19:07, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference.
Re: [Pharo-dev] specialSelectors
On Tue, Sep 3, 2013 at 7:14 PM, Camillo Bruni camillobr...@gmail.comwrote: that would actually be interesting on how much you win by doing so, and if you could run this dynamically (for instance reintroduce the #class optimization if you never override it in the image)... Please don't. Sometimes this is useful for proxies On 2013-09-03, at 19:07, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference. -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] specialSelectors
Hmm... my timings are not reliable, I tried again with IRByteCodeGenerator specialSelectorsArray ^ #(#+ 1 #- 1 # 1 # 1 #= 1 #= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 nil 0 nil 0 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) Recompiled all: IRBytecodeGenerator initializeSpecialSelectors. Smalltalk specialObjectsArray at: 24 put: IRBytecodeGenerator specialSelectorsArray. OpalCompiler recompileAll. and got a fast run 84446 too without optimizing assert: so it looks just like a space optimization. 2013/9/4 Nicolas Cellier nicolas.cellier.aka.n...@gmail.com Well, #class slot is not really available because the trick is hardcoded in the VM as well as == trick, so no lookup in specialSelectors (specailObjectsArray at: 24) is attempted for these 2. COG also optimize some arithmetic messages, comparisons, bit ops, and all is hardcoded in the VM, so better not playing with those indices. So I tried to just replace #blockCopy: 1 with #not 0, ran some tests but saw no significative speed up. Then I tried to run Kernel tests twice in a unmodified 3.0 image [(Smalltalk allClasses select: [:e | (e category beginsWith: 'KernelTests') and: [e inheritsFrom: TestCase]]) do: [:e | e suite run]] timeToRun. 113342 114337 Then optimized the mosttly sent message during tests : IRByteCodeGeneratorspecialSelectorsArray ^ #(#+ 1 #- 1 # 1 # 1 #= 1 #= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 nil 0 #assert: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) Recompiled all: IRBytecodeGenerator initializeSpecialSelectors. Smalltalk specialObjectsArray at: 24 put: IRBytecodeGenerator specialSelectorsArray. OpalCompiler recompileAll. Then tried the tests twice again: [(Smalltalk allClasses select: [:e | (e category beginsWith: 'KernelTests') and: [e inheritsFrom: TestCase]]) do: [:e | e suite run]] timeToRun. 84328 83974 So it seems like it's not just a space optimization but also a speed one, and I don't know why... It would be better if someone could repeat these results... Nicolas 2013/9/4 Camillo Bruni camillobr...@gmail.com that would actually be interesting on how much you win by doing so, and if you could run this dynamically (for instance reintroduce the #class optimization if you never override it in the image)... On 2013-09-03, at 19:07, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference.
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false Dave platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- 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 -- 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
