Re: [Pharo-project] Compiling the VM for MacOSX
alex do not forget to update the web page with the information you learned.
On Sep 8, 2010, at 12:44 AM, Alexandre Bergel wrote:
Thanks, it works fine now.
I use an obsolete version? Strange. I downloaded the lastest version of
VMMaker. By the way, the produced vm is fairly slow. I do not know whether
there is an option somewhere for inline or something...
Thanks,
Alexandre
On 7 Sep 2010, at 15:05, John M McIntosh wrote:
Ah well actually you are attempting to build an obsolete VM. However we
might as well ensure you can do that for historical reasons.
I'm not sure why the setMicroSecondsandOffset does not resolve into a
default setMicroSecondsandOffset in the interp.c
since mine has
/* A default substitute for unimplemented ioUtcWithOffset external
function. */
sqInt setMicroSecondsandOffset(sqLong * microSeconds, int * utcOffset) {
flag(toRemove);
return -1;
}
However buried in a email message from last March is a slight error which
prevented the ioUtcWithOffset() defined in sqMacTime.c
from being used. Therefore I've altered sqMacTime.c
sqPlatformSpecific.h in the Mac OS carbon SVN tree. You should check
out a new copy of that.
Ok, so building an obsolete VM might be fun and let's see if you can do it,
but you should build a 5.x VM from the iOS tree.
See platform/iOS/vm/SqueakPureObjc.xcodeproj in order to build
SqueakPureObjc The cocoa based 5.x VM for OSX 32bit
64bit supporting a 32bit image format
SqueakPureObjc64*64 The cocoa based 5.x VM for OSX 64bit supporting a 64bit
image format
SqueakNoOGLIPhoneThe cocoa based 2.x VM for the iOS devices
Also lurking in there is the
SqueakPureObjcCogVM.xcodeproj
which lets you build:
SqueakNoOGLIPhoneThe cocoa based Cog Stack Based VM for iOS devices
SqueakPureObjc The cocoa based Cog JIT VM for OSX
32bit.
However that xcodeproj is still a work in progress and Eliot and I are still
merging changes.
Later open SqueakPureObjc.xcodeproj
compile link you'll find a pre-existing src file that is somewhat current.
Swap in a newer one if needbe.
On 2010-09-07, at 10:00 AM, Alexandre Bergel wrote:
Undefined symbols:
_setMicroSecondsandOffset, referenced from:
_primitiveUtcWithOffset in interp.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Where this _setMicroSecondsandOffset is defined?
No idea whether this is related or not, but I had to leave TestOSAPlugin
out when generating the vm code. This plugin cannot be produced apparently,
a class is missing.
Cheers,
Alexandre
--
===
John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] UbiquiTalk running in Pharo 1.1
sean I do not know your computer but mine does not have a 5 inches floppy, 3.5 floppy, serial port, RS2332. Does it answer your question? Side remark: lukas probably write gofer because he needed something - well written - robust - small with only the code he needs - with tests so he did it and instead of keeping it for himself he accepted the **hassle** - to get pointed as a bad guy, - merge our changes And we all thank him for that! Lukas and other continue to rewrite everything you want :) I have a long list in my pocket (changelist, messageset, ...) So changes is good, non backward compatibility is good (look at apple). Let us face it and learn. Stef Miguel Enrique Cobá Martínez-2 wrote: Exactly, that is the reason that I put AFAIK, and the reason I said it was bloated. The fact that you can download from a Mantis, squeakmap, GOODs, a magma repo, universes or a ftp repo has little impact if 99% of the times you are downloading from http repos squeaksource and gemstone. :) [thinking out loud] This sounds like a great reason to clean and modularize, but why a whole new thing. -- View this message in context: http://forum.world.st/UbiquiTalk-running-in-Pharo-1-1-tp2400767p2530693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] yarg: Pharo grammar ...
- Check out the Parser/Scanner classes in every PharoDev image. - Check out the RBParser/RBScanner classes in the package AST-Core in every Pharo image. - Check out the class PPSmalltalkGrammar in the package PetitSmalltalk (http://scg.unibe.ch/research/helvetia/petitparser) which is an executable Smalltalk grammar that almost looks like an EBNF. Lukas 2010/9/8 James Ladd james_l...@hotmail.com: This is Yet Another Request for the Grammar to Pharo/Squeak Smalltalk? I have seen this: http://wiki.squeak.org/squeak/409 but it is very old and doesn't appear to cater for Pharo/Squeak additions. Can someone point me to a more recent grammar? Rgs, James. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] yarg: Pharo grammar ...
On Sep 8, 2010, at 4:51 AM, James Ladd wrote: This is Yet Another Request for the Grammar to Pharo/Squeak Smalltalk? I have seen this: http://wiki.squeak.org/squeak/409 but it is very old and doesn't appear to cater for Pharo/Squeak additions. Can someone point me to a more recent grammar? Lukas did a grammar for Smalltalk with PetitParser. This has many additional benefits over a traditional dead form of EBNF that it is - executable. It's just Smallltak. Smalltalk grammar described in Smalltalk. So executing this code, you have a parser. - reflective dynamic grammar. After executing, the parser is a graph of smaller parser=objects that you can inspect, modify and compose. http://www.lukas-renggli.ch/blog/petitparser-1 http://scg.unibe.ch/archive/papers/Reng10cDynamicGrammars.pdf Gofer new renggli: 'petit'; package: 'PetitParser'; load. Gofer new renggli: 'petit'; package: 'PetitSmalltalk'; load. Alternatively, I will send you the SmaCC grammar we originally used in the compiler. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
On 7 September 2010 21:15, Philippe Marschall kus...@gmx.net wrote: On 07.09.2010 09:03, Andreas Raab wrote: Hi - After careful consideration I've decided to put WebClient under the MIT license, and updated the repository at http://www.squeaksource.com/WebClient.html to reflect the license change. If you're curious why I'm making the change, the answer is really that the code isn't all that unique and even though I'm not done with it it's good enough to be released and by now I simply get more benefits from it being thoroughly tested by as many people as possible. That and the (to me surprising) amount of interest that WebClient has received in combination with the (to me disturbing) lack of due diligence that many users of WebClient apparently have. I think we can all take away a lesson from this little incident that even if you find some random code on the net it doesn't mean it's up for grabs. Also, if I may be so bold, let me propose the 2 step process to eternal license happiness. It's really simple: [ ] Did we check the license of the package? [ ] Did we contact the author of the package? If you check off the above two steps whenever you're about to use some third-party code, I think you'll find that situations like the one we've encountered here are virtually impossible. Attach the steps to the bug tracker if you must, but follow them. Since you know how to verify the license status on your own, let me add the second step of the process and once more repeat that I would rather keep WebClient an externally loadable package. If at all possible I urge you to look at what has been done with HTTPSocket in Squeak and adopt a similar approach; that is provide a minimal internal HTTP interface and allow third-party libraries (WebClient or other) to hook into this interface. There is really no need to have everything tied together at the hip; HTTPSocket is a reasonable facade for HTTP requests in the kernel. Regarding write access to the WebClient repository, I'm not a fan of making repos world-writable (this is really a sign of abandonware) but due to the license I'm fine with granting Sven and Philippe write access if they want it (drop me a note if you do). Did you change your position towards #squeakToUtf8 and string concatenation (I didn't follow the entire previous thread)? Otherwise it would probably make more sense if I continue sending patches. Now don't get me wrong, you're of course allowed to write code whichever way you see fit and reject anything that doesn't follow this. But the same goes for me. And for me it's important that code loads without any overrides. So I'm probably going to set up a WebClientPharo or WebClientPhilippe or something repository. How about extra package in same repository (WebClient)? This is, of course, if you can't avoid it. Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.
Ok, I was going to spend a few of my precious evenings going thru and rebuilding all/some of the plugins for the Cocoa V5.x series of VMs. Maybe even update them for the Cog Stack and JIT VM. However to do this I need some help from the community to test the creatures after they are done. This evening I rebuild the Locale plugin and checked it into SVN to close this Pharo issue: http://code.google.com/p/pharo/issues/detail?id=2660 Now the problem is the Smalltalk code Locale for talking to this plugin sucks, it doesn't actually call most of the primitives and there aren't any tests. Obviously if no-cares about using the plugin then I can't be bothered to poke at it. However I did write some Objective-C code and jiggle it with a stick. Therefore someone should write some tests, fix the Locale Class, etc and tell me if the plugin is sane. You'll find the plugin in the Experimental Folder sub folder 5.x Plugins http://homepage.mac.com/johnmci/.Public/experimental/5.x%20Plugins/LocalePlugin.bundle.zip Just unzip and drop it into the *.app/Contents/Resources/ folder Now this might work with Squeak 4.x VMs, I've not tried it. It might work with 64bit VMs (5.7x), I've not tried it. It might work on PowerPC, I've not tried it. It should work on the 5.8x series but I've not tried it out of canadian english, metric, PST, daylight savings time, georgian calendar settings so I have no idea if it works oh say in France where you use Euros versus $ signs? I've not bothered ported to iOS devices since it's unclear if anyone supports the Locale class? Lastly I'll take suggestions on which plugin to rework next. -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Why -encoding latin1 in pharo.sh?
Hi all! A friend of mine wondered why he couldn't copy/paste a text in UTF8 (with swedish åäö characters in it) and paste into Pharo without getting a debugger :) It turns out that the One-Click pharo.sh uses -encoding latin1 when it starts the VM. But the code in ClipboardclipboardText evidently presumes that clipboard is coming in as UTF8 always - might be the new clipboard plugin that Michael did that does that? Anyway, why is pharo.sh using -encoding latin1? It works fine when that option is removed. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
On 08.09.2010 08:35, Igor Stasenko wrote: On 7 September 2010 21:15, Philippe Marschall kus...@gmx.net wrote: On 07.09.2010 09:03, Andreas Raab wrote: Hi - After careful consideration I've decided to put WebClient under the MIT license, and updated the repository at http://www.squeaksource.com/WebClient.html to reflect the license change. If you're curious why I'm making the change, the answer is really that the code isn't all that unique and even though I'm not done with it it's good enough to be released and by now I simply get more benefits from it being thoroughly tested by as many people as possible. That and the (to me surprising) amount of interest that WebClient has received in combination with the (to me disturbing) lack of due diligence that many users of WebClient apparently have. I think we can all take away a lesson from this little incident that even if you find some random code on the net it doesn't mean it's up for grabs. Also, if I may be so bold, let me propose the 2 step process to eternal license happiness. It's really simple: [ ] Did we check the license of the package? [ ] Did we contact the author of the package? If you check off the above two steps whenever you're about to use some third-party code, I think you'll find that situations like the one we've encountered here are virtually impossible. Attach the steps to the bug tracker if you must, but follow them. Since you know how to verify the license status on your own, let me add the second step of the process and once more repeat that I would rather keep WebClient an externally loadable package. If at all possible I urge you to look at what has been done with HTTPSocket in Squeak and adopt a similar approach; that is provide a minimal internal HTTP interface and allow third-party libraries (WebClient or other) to hook into this interface. There is really no need to have everything tied together at the hip; HTTPSocket is a reasonable facade for HTTP requests in the kernel. Regarding write access to the WebClient repository, I'm not a fan of making repos world-writable (this is really a sign of abandonware) but due to the license I'm fine with granting Sven and Philippe write access if they want it (drop me a note if you do). Did you change your position towards #squeakToUtf8 and string concatenation (I didn't follow the entire previous thread)? Otherwise it would probably make more sense if I continue sending patches. Now don't get me wrong, you're of course allowed to write code whichever way you see fit and reject anything that doesn't follow this. But the same goes for me. And for me it's important that code loads without any overrides. So I'm probably going to set up a WebClientPharo or WebClientPhilippe or something repository. How about extra package in same repository (WebClient)? I believe I just addressed that in the previous paragraph. Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.
On 08.09.2010 09:11, John M McIntosh wrote: Ok, I was going to spend a few of my precious evenings going thru and rebuilding all/some of the plugins for the Cocoa V5.x series of VMs. Maybe even update them for the Cog Stack and JIT VM. However to do this I need some help from the community to test the creatures after they are done. This evening I rebuild the Locale plugin and checked it into SVN to close this Pharo issue: http://code.google.com/p/pharo/issues/detail?id=2660 Now the problem is the Smalltalk code Locale for talking to this plugin sucks, it doesn't actually call most of the primitives and there aren't any tests. Obviously if no-cares about using the plugin then I can't be bothered to poke at it. However I did write some Objective-C code and jiggle it with a stick. Therefore someone should write some tests, fix the Locale Class, etc and tell me if the plugin is sane. You'll find the plugin in the Experimental Folder sub folder 5.x Plugins http://homepage.mac.com/johnmci/.Public/experimental/5.x%20Plugins/LocalePlugin.bundle.zip Just unzip and drop it into the *.app/Contents/Resources/ folder Now this might work with Squeak 4.x VMs, I've not tried it. It might work with 64bit VMs (5.7x), I've not tried it. It might work on PowerPC, I've not tried it. It should work on the 5.8x series but I've not tried it out of canadian english, metric, PST, daylight savings time, georgian calendar settings so I have no idea if it works oh say in France where you use Euros versus $ signs? Seems to work at first glance. I'll see what I can do about the Locale class and tests. I've not bothered ported to iOS devices since it's unclear if anyone supports the Locale class? Lastly I'll take suggestions on which plugin to rework next. What does SqueakFFIPrims do exactly? I sounds kinda important. Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why -encoding latin1 in pharo.sh?
thanks for reporting ;) Stef On Sep 8, 2010, at 10:16 AM, Göran Krampe wrote: Hi all! A friend of mine wondered why he couldn't copy/paste a text in UTF8 (with swedish åäö characters in it) and paste into Pharo without getting a debugger :) It turns out that the One-Click pharo.sh uses -encoding latin1 when it starts the VM. But the code in ClipboardclipboardText evidently presumes that clipboard is coming in as UTF8 always - might be the new clipboard plugin that Michael did that does that? Anyway, why is pharo.sh using -encoding latin1? It works fine when that option is removed. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] simpleLog in pharo?
+ 1 If someone could look at simpleLog (because we need to change this situation and get a good logging mechanism) We need much better infrastructure and we will build them. this is on my todo but this is a long one. On Sep 8, 2010, at 10:09 AM, Simon Denier wrote: I have no idea whether this issue has been discussed before, and perhaps even solved, but is there an easy way to configure Metacello logging? Right now in Pharo, it goes into the Transcript, and consequently mixes with Compiler warning and other stuff. When we load ConfigurationOfMoose, there are so many items in the Transcript that we lost the first ones. We have to hack the Transcript to dump the interesting info into a file. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.
On 08.09.2010 11:23, Philippe Marschall wrote: On 08.09.2010 09:11, John M McIntosh wrote: Ok, I was going to spend a few of my precious evenings going thru and rebuilding all/some of the plugins for the Cocoa V5.x series of VMs. Maybe even update them for the Cog Stack and JIT VM. However to do this I need some help from the community to test the creatures after they are done. This evening I rebuild the Locale plugin and checked it into SVN to close this Pharo issue: http://code.google.com/p/pharo/issues/detail?id=2660 Now the problem is the Smalltalk code Locale for talking to this plugin sucks, it doesn't actually call most of the primitives and there aren't any tests. Obviously if no-cares about using the plugin then I can't be bothered to poke at it. However I did write some Objective-C code and jiggle it with a stick. Therefore someone should write some tests, fix the Locale Class, etc and tell me if the plugin is sane. You'll find the plugin in the Experimental Folder sub folder 5.x Plugins http://homepage.mac.com/johnmci/.Public/experimental/5.x%20Plugins/LocalePlugin.bundle.zip Just unzip and drop it into the *.app/Contents/Resources/ folder Now this might work with Squeak 4.x VMs, I've not tried it. It might work with 64bit VMs (5.7x), I've not tried it. It might work on PowerPC, I've not tried it. It should work on the 5.8x series but I've not tried it out of canadian english, metric, PST, daylight savings time, georgian calendar settings so I have no idea if it works oh say in France where you use Euros versus $ signs? Seems to work at first glance. I'll see what I can do about the Locale class and tests. Ok, see the code attached to the bug. A couple of notes: - If a primitive fails, you now get a #primitiveFailed which gives you the most generic error but anyways you know something went wrong instead of giving you some random data (eg. the country was hardcoded to 'FR'). - #primCountry and #primLanguage seem to answer a three element String with the last element being a zero character (I assume a C string), this is not so nice. I'm not sure whether this should be fixed in the primitive or in the Pharo code. - All the primitives seem to totally ignore the locale id and only work on the system locale. This makes it a whole lot less useful. - I'm totally confused by the Current and CurrentPlatform class variables. What's the difference? Do we really need both? - I'm confused by #isoCountry vs #primCountry and #isoLangauge vs #primLanguage. Do we need both? What's the point? Is this what you meant which cleanup? Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
On 09/08/2010 11:45 AM, Stéphane Ducasse wrote: + 1 If someone could look at simpleLog (because we need to change this situation and get a good logging mechanism) We need much better infrastructure and we will build them. I wrote SimpleLog (in the Gjallar project) and feel free to pick/use it - it is small and maps easily to Syslog (I copied the levels that syslog has) and also has a syslog emitter which is *very* nice when you build Seaside apps and want to run multiple images with a load balancer in front for example. There are several logging libs but... well, I think SimpleLog strikes a nice balance of functionality and simplicity. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
I will chekc I would like an object that represent wht is logged. do you have that? I do not want strings strings strings. On Sep 8, 2010, at 12:39 PM, Göran Krampe wrote: On 09/08/2010 11:45 AM, Stéphane Ducasse wrote: + 1 If someone could look at simpleLog (because we need to change this situation and get a good logging mechanism) We need much better infrastructure and we will build them. I wrote SimpleLog (in the Gjallar project) and feel free to pick/use it - it is small and maps easily to Syslog (I copied the levels that syslog has) and also has a syslog emitter which is *very* nice when you build Seaside apps and want to run multiple images with a load balancer in front for example. There are several logging libs but... well, I think SimpleLog strikes a nice balance of functionality and simplicity. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b7
John M McIntosh wrote:
Ok, well it's great someone is actually paying attention.
In 4.2.4
if (stat(unixPath, statBuf) lstat(unixPath, statBuf))
and pull these values
time_t st_mtime; /* [XSI] Last data modification time */
time_t st_ctime; /* [XSI] Time of last status change */
For your examples the lstat() is the one populating the structure.
Also described in the man page as the time file was last accessed or modified,
of when the inode was last changed, or the birth time of the inode.
We then consider
localtime(unixTime)-tm_gmtoff;
to create a time in the Squeak epoch.
Now for the Cocoa Version we take
NSFileCreationDate The key in a file attribute dictionary whose value indicates
the file's creation date.
NSFileModificationDate The key in a file attribute dictionary whose value
indicates the file's last modified date.
{
NSFileCreationDate = 2010-08-20 13:25:54 -0700;
NSFileExtendedAttributes = {
com.apple.quarantine = 30303030 3b346337 36396138 623b5361 66617269
2e617070 3b7c636f 6d2e6170 706c652e 53616661 7269;
};
NSFileExtensionHidden = 0;
NSFileGroupOwnerAccountID = 0;
NSFileGroupOwnerAccountName = wheel;
NSFileHFSCreatorCode = 1178686292;
NSFileHFSTypeCode = 1398039400;
NSFileModificationDate = 2010-09-06 18:00:05 -0700;
NSFileOwnerAccountID = 501;
NSFileOwnerAccountName = johnmci;
NSFilePosixPermissions = 420;
NSFileReferenceCount = 1;
NSFileSize = 4073312;
NSFileSystemFileNumber = 81731241;
NSFileSystemNumber = 234881026;
NSFileType = NSFileTypeRegular;
}
Now actually another bug is that I'm not re-calculating for DayLightSavings time.
I've fixed that for 5.8b10 where the date below shows as 17:00:05 but really it should be 18:00:05
In checking the creation time in Squeak I see it thinks it is 2010-08-20T13:25:54+00:00 which baring the timezone/daylightsavings +00.00? issue seems correctly stated.
Let me send you a 5.8b10 VM to test
/Users/johnmci/Shared/TextFlow-trunk/trunk.changes
On 2010-09-07, at 9:53 AM, Juan Vuletich wrote:
John M McIntosh wrote:
I've stuck a version (5.8b7) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. Please ensure drawing looks sane, and how it interacts with the mouse and keyboard seems viable.
http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b7.app.zip
I finished the open/GL tuning and based on benchmarking I simplified the
explicit flush required when a Smalltalk Morphic draw cycle fails to do a
flush. Lastly I cross check the source code to ensure it compiles
correctly for the iOS platform.
--
===
John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
==
Hi John,
I found something strange with reported file creation and modification time.
The values answered by #primLookupEntryIn:index: are (Tested on Squeak 4.1, Mac
OS 10.5.8):
4.2.4 VM (Stack VM):
3461318674 3461318674 newFile
3449660476 3447966888 Squeak 4.2.4beta1U.app
3460975777 3460916669 Squeak.app
3460551046 3460551046 Squeak4.1.image
3449660435 3448977726 SqueakV41.sources
5.8b7 (Cog experimental VM)
3461314066 3461314066 newFile
3447962280 3447962280 Squeak 4.2.4beta1U.app
3460912061 3460912061 Squeak.app
3448973124 3460546438 Squeak4.1.image
3448973118 3448973118 SqueakV41.sources
Take for instance SqueakV41.sources:
DateAndTime fromSeconds: 3449660435 2010-04-25T15:00:35-03:00
DateAndTime fromSeconds: 3448977726 2010-04-17T17:22:06-03:00 This is
the correct one according to Finder, 4.2.4 modification time
DateAndTime fromSeconds: 3448973118 2010-04-17T16:05:18-03:00
DateAndTime fromSeconds: 3448973118 2010-04-17T16:05:18-03:00
So I'm, getting incorrect time info in the FileList.
Something else I see is that 4.2.4 VM answers the same value for creation and
modification time for some files, while 5.8b7 answers the same value for other files.
(Why?) For the newly created newFile, both answer the same value for creation
and modification time. The correct value is (again) the one answered by 4.2.4.
I'm at the ART time zone.
Thanks,
Juan Vuletich
--
===
John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===
Hi John,
Re: [Pharo-project] Pharo sprint Friday 1 of October @ Lille
You can count me in. Johan (from a sunny place :-) On 06 Sep 2010, at 15:27, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys we want to do a pharo sprint the friday 1st of October. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] RFB Server not working on Squeak 4.1?
Has anyone tested the RFB server class in Squeak 4.1? I can't get it to work in Mac OS X 10.6 or in at least variant of Linux. Haven't tested it in Pharo. Lawson ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] UbiquiTalk running in Pharo 1.1
El mié, 08-09-2010 a las 08:18 +0200, Stéphane Ducasse escribió: sean I do not know your computer but mine does not have a 5 inches floppy, 3.5 floppy, serial port, RS2332. Does it answer your question? Side remark: lukas probably write gofer because he needed something - well written - robust - small with only the code he needs - with tests so he did it and instead of keeping it for himself he accepted the **hassle** - to get pointed as a bad guy, - merge our changes And we all thank him for that! Lukas and other continue to rewrite everything you want :) I have a long list in my pocket (changelist, messageset, ...) So changes is good, non backward compatibility is good (look at apple). +100 :) Let us face it and learn. Stef Miguel Enrique Cobá Martínez-2 wrote: Exactly, that is the reason that I put AFAIK, and the reason I said it was bloated. The fact that you can download from a Mantis, squeakmap, GOODs, a magma repo, universes or a ftp repo has little impact if 99% of the times you are downloading from http repos squeaksource and gemstone. :) [thinking out loud] This sounds like a great reason to clean and modularize, but why a whole new thing. -- View this message in context: http://forum.world.st/UbiquiTalk-running-in-Pharo-1-1-tp2400767p2530693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo sprint Friday 1 of October @ Lille
I added you in http://code.google.com/p/pharo/wiki/PharoSprints Are there topics to do? I would like to remove CodeLoader and also to create a Pharo 1.1.1 Covg one click. Cheers Mariano On Wed, Sep 8, 2010 at 3:41 PM, Johan Brichau jo...@inceptive.be wrote: You can count me in. Johan (from a sunny place :-) On 06 Sep 2010, at 15:27, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys we want to do a pharo sprint the friday 1st of October. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Magma in Pharo 1.1
After an afternoon of trying to install Magma, I find you also need to select the compiler option to allow assignments to block variables. I still get dependency warnings, which I ignored by clicking on 'Proceed': This package depends on the following classes: FlapTab You must resolve these dependencies before you will be able to load these definitions: FlapTab classSidemaMaterializeFromGraph:using: FlapTabmaAsStorageObject FlapTabmaUsesStandardStorage and This package depends on the following classes: FlapTab You must resolve these dependencies before you will be able to load these definitions: FlapTabisImmutableInMagma The installation runs through now, but Magma doesn't work, the class 'MagmaRepositoryController' isn't there, and although I only want to run a 'single-user' image, the method MagmaSession openLocal: doesn't exist either. Can anybody help? David -- View this message in context: http://forum.world.st/Magma-in-Pharo-1-1-tp2253709p2531491.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Magma in Pharo 1.1
El mié, 08-09-2010 a las 08:24 -0700, DavidWilson escribió: After an afternoon of trying to install Magma, I find you also need to select the compiler option to allow assignments to block variables. You don't say how are you installing Magma, from the sar from the mcm, from the metacello configuration. In general for Pharo, the official way to install it is with the metacello configuration announced in http://lists.squeakfoundation.org/pipermail/magma/2010-August/001587.html Though that announce was made befor the renaming of the repositories from UnivesreForPharoXX to MetaRepoForPharoXX. I just forgot to reannounce the new workspace snippets :) Anyway, the correct do its are: Gofer new squeaksource: 'MetaRepoForPharo11'; package: 'ConfigurationOfMagma'; load. and then, any of: ConfigurationOfMagma project latestVersion load: 'Client'. ConfigurationOfMagma project latestVersion load: 'Server'. ConfigurationOfMagma project latestVersion load: 'Tester'. depending of what level of magma you want. This will install Magma 1.1r2. If you want a previous version of Magma, you should do: (ConfigurationOfMagma project version: '1.1r1') load: 'Client'. (ConfigurationOfMagma project version: '1.1r1') load: 'Server'. (ConfigurationOfMagma project version: '1.1r1') load: 'Tester'. Cheers -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] RFB Server not working on Squeak 4.1?
On Wed, 8 Sep 2010, Lawson English wrote: Has anyone tested the RFB server class in Squeak 4.1? I can't get it to work in Mac OS X 10.6 or in at least variant of Linux. Haven't tested it in Pharo. If you're talking about http://squeaksource.com/RFB/ then yes, we use it (actually we use our own fork, but it's very similar) and it works fine. There are 2 other forks, one in the Cobalt repo, and one in Lukas Renggli's repo. I don't know if the first one works in Squeak, but the latter relies on Pharo-specific features (IIRC it requires Polymorph, but I'm not sure). Levente Lawson ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Magma in Pharo 1.1
Hi Miguel I'd tried all three methods I found (Monticello, Installer, and Gofer ). Now I've done what you suggested and the install works perfectly. And Magma seems to work. Thanks for your help. David -- View this message in context: http://forum.world.st/Magma-in-Pharo-1-1-tp2253709p2531567.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo sprint Friday 1 of October @ Lille
Can you add luc and me too please :-) Noury On 8 sept. 2010, at 17:16, Mariano Martinez Peck wrote: I added you in http://code.google.com/p/pharo/wiki/PharoSprints Are there topics to do? I would like to remove CodeLoader and also to create a Pharo 1.1.1 Covg one click. Cheers Mariano On Wed, Sep 8, 2010 at 3:41 PM, Johan Brichau jo...@inceptive.be wrote: You can count me in. Johan (from a sunny place :-) On 06 Sep 2010, at 15:27, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys we want to do a pharo sprint the friday 1st of October. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b7
Hi John, I've just tested the new VM you sent me. The details are below. This is what I see: 1)- 5.8b10 gives exactly the same date/times as 5.8b7 2)- 5.8 (both) seem to show times that are about 1:17 (one hour, seventeen minutes) earlier than the correct one. This doesn't have relation with time zones or daylight savings, it is a constant number of seconds, but not entire hours. May be it is related to the Mac OS version? I'm using MacOS 10.5.8. 3)- 5.8 (both) agree with Macintosh Explorer on when creation time should equal modification time. This is good. I believe that the new API is the correct one, even if still off by 01:17. 4)- 4.2.4 seems to know my time zone (-03:00), 5.8 (both) seem not to know. 5)- Creation time for 4.2.4 seems just wrong. Some times it is the same as modification time (when it shouldnt). Some times it doesn't make sense to me. I believe you should see similar results on your system, right? Thanks, Juan Vuletich Well I think I know what the issue is, Juan can you tell me what timezone and city you have set in the Date Time TimeZone tab in system settings? -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo sprint Friday 1 of October @ Lille
Cool! and Welcome of course. Stef On Sep 8, 2010, at 3:41 PM, Johan Brichau wrote: You can count me in. Johan (from a sunny place :-) On 06 Sep 2010, at 15:27, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi guys we want to do a pharo sprint the friday 1st of October. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] UbiquiTalk running in Pharo 1.1
Yes we should have some nice parties :) Stef On Sep 8, 2010, at 5:16 PM, Sean P. DeNigris wrote: Stéphane Ducasse wrote: Side remark: lukas probably write gofer because he needed something - well written - robust - small with only the code he needs - with tests so he did it and instead of keeping it for himself he accepted the **hassle** - to get pointed as a bad guy, - merge our changes And we all thank him for that! snip So changes is good, non backward compatibility is good (look at apple). Let us face it and learn. Okay, thank you for the explanation. And thank you Lukas for doing that work. See you at ESUG!!! Sean -- View this message in context: http://forum.world.st/UbiquiTalk-running-in-Pharo-1-1-tp2400767p2531477.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12125
12125 - - Issue 2778: Replace ParagraphEditor by TextEditor and SmalltalkEditor. Thanks Guillermo Polito. Now we should fix the menus :) Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Sockets in Pharo CollaborActive Book
On 5 sept. 2010, at 03:22, Schwab,Wilhelm K wrote: Noury, I was struggling a little with a stream for serial ports, and thought you might have tackled the problem of a generating stream (one that can grow in the background). Now that I type that, maybe Nile has the answer?? Re Ocean, I grabbed a .mcz from SqueakSource and simply browsed the main package. Some comments: (1) no socket stream :( Streams are really slick things, and good read and write stream semantics should exist for sockets. FWIW, Dolphin separates the socket read and write streams, and we might do well to follow their lead. Not yet ;-) So far, we want to have a clean socket. And then we'll rebuild a SocketStream on top of it. (2) ByteArrayasAlien loops over the bytes. Do all the bounds checking you want up front (once) and then use memcpy() or something to actually transfer the data. It recently came to my attention that Squeak has no formalized approach to access, copy and move external memory; Pharo needs to offer that, and this is a good place to start. Thanks for the hint. (3) You are planning to attack ipv4 vs. 6 with polymorphism - good call!! Yes. One reason behind doing Ocean is that we found existing library too dirty to improve. So, we try to have a well designed tested library. (4) OCNTcpSocketsend: sizes a buffer to match the data provided to it. I'm not sure I like that. You might consider renaming your current #send: to #basicSend: and adding something like send:blob | in | in := blob readStream. [ in atEnd ] whileFalse:[ self basicSend:( in nextAvailable:self alienDataBufferSize ). ]. so that a fixed buffer (which will have to be allocated when the socket is opened) is used to send large blobs in buffer-sized chunks. Better still would be to use array indexing to cope with the blob in pieces but in place to skip the copying. We discussed this with Luc. And the rational behind our decision to do it this way is that Socket is but a basic wrapper for the actual OS socket. It shouldn't provide any extra features. Spliting a blob is something I'd rather do by using a SocketStream. Thanx for the feedback, Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.
On 2010-09-08, at 3:34 AM, Philippe Marschall wrote: - #primCountry and #primLanguage seem to answer a three element String with the last element being a zero character (I assume a C string), this is not so nice. I'm not sure whether this should be fixed in the primitive or in the Pharo code. The primitive is answering a ISO 639-1 value (2 character) versus the ISO 639-2 value (3 character) I have to figure out how to get the ISO 639-2 data, but it seems in looking it appears you'll get the 2 character code versus the 3 character code on other platforms so I'll bet you need to deal with the case of 2 character codes. The plugin assumes a 3 character value which is why you get the trailing null char. You'll need to deal with it. - All the primitives seem to totally ignore the locale id and only work on the system locale. This makes it a whole lot less useful. ? explain ? In the primitive I ask for autoupdatingCurrentLocale The current logical locale for the current user. The locale is formed from the settings for the current user’s chosen system locale overlaid with any custom settings the user has specified in System Preferences. The object always reflects the current state of the current user's locale settings. - I'm totally confused by the Current and CurrentPlatform class variables. What's the difference? Do we really need both? - I'm confused by #isoCountry vs #primCountry and #isoLangauge vs #primLanguage. Do we need both? What's the point? Is this what you meant which cleanup? Yes that would be cleanup.. There is also issues withe currency symbol, the logic assumes it's one byte, but it could be a unicode value if you decide between the international symbol versus localized regional symbol. I think the plugin is flawed in that respect. -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Issue reported: Category inconsistency in ClassDescription
I have added a new issue to the tracker: http://code.google.com/p/pharo/issues/detail?id=2918 Description: If you browse the ClassDescription class you will find two different categories that I think conceptually are the same: filein/out and fileIn/Out (just a casing difference). Regards Nico. blog: nicopaez.wordpress.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Hudson
Would someone give a brief summary of how Hudson is being used by Pharo? (I googled and have a general understanding of what Hudson is) Thanks. Sean -- View this message in context: http://forum.world.st/Hudson-tp2531857p2531857.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issue reported: Category inconsistency in ClassDescription
Thanks! On Sep 8, 2010, at 8:50 PM, Nicolás Paez wrote: I have added a new issue to the tracker: http://code.google.com/p/pharo/issues/detail?id=2918 Description: If you browse the ClassDescription class you will find two different categories that I think conceptually are the same: filein/out and fileIn/Out (just a casing difference). Regards Nico. blog: nicopaez.wordpress.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hudson
Gees if you spoil the secret in advance :) Luckily we have the secret talks on wednesday and even mariano failed to know what it will be :) Stef On Sep 8, 2010, at 9:18 PM, Lukas Renggli wrote: Did you check the README file of the distribution? http://github.com/renggli/builder Also come to my ESUG presentation on Thursday titled Agile Seaside, I might show Hudson there :-) Lukas On 8 September 2010 21:07, Sean P. DeNigris s...@clipperadams.com wrote: Would someone give a brief summary of how Hudson is being used by Pharo? (I googled and have a general understanding of what Hudson is) Thanks. Sean -- View this message in context: http://forum.world.st/Hudson-tp2531857p2531857.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hudson
On Sep 8, 2010, at 9:48 PM, Lukas Renggli wrote: Luckily we have the secret talks on wednesday and even mariano failed to know what it will be :) Do the presenters of the secret talks know that they will present something? why you stress? LOL You gave me some great ideas But normally not. :) Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
Stéphane Ducasse wrote: I will chekc I would like an object that represent wht is logged. do you have that? I do not want strings strings strings. On Sep 8, 2010, at 12:39 PM, Göran Krampe wrote: On 09/08/2010 11:45 AM, Stéphane Ducasse wrote: + 1 If someone could look at simpleLog (because we need to change this situation and get a good logging mechanism) We need much better infrastructure and we will build them. I wrote SimpleLog (in the Gjallar project) and feel free to pick/use it - it is small and maps easily to Syslog (I copied the levels that syslog has) and also has a syslog emitter which is *very* nice when you build Seaside apps and want to run multiple images with a load balancer in front for example. There are several logging libs but... well, I think SimpleLog strikes a nice balance of functionality and simplicity. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project In GLASS we have the ObjectLog ... the implementation is based upon RCQueue's (so that multiple vm's can concurrently add entries), but it is can be thought of as an OrderedCollection ObjectLogEntry instances: Object subclass: 'ObjectLogEntry' instVarNames: #( pid stamp label priority object tag) classVars: #( ObjectLog ObjectQueue) classInstVars: #() poolDictionaries: #[] inDictionary: '' category: 'Bootstrap-Gemstone' The pid and ObjectQueue are GemStone-specific ... - stamp DateAndTime - label String - priority Integer - object Object - tag Object GLASS has an ObjectLog component for viewing the object log ... inspector for in-image-viewing. There are currently 7 priorities defined: fatal - 1 error - 2 warn - 3 info - 4 debug - 5 trace - 6 transcript - 7 Yes Transcript messages are added to the ObjectLog ... very convenient ... Entries are added to the log via something like the following: (ObjectLogEntry info: 'label string' object: #( #hello 'world') addToLog. For GLASS I have a handful of subclasses of ObjectLogEntry that store things like a continuation and/or the url that caused the error... Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12126
After this little breaks in integration I feel another wave of good fixes before ESUG :) At ESUG I'm in the mood to have regular hacking sessions will be fun. 12126 - - Issue 2918: Category inconsistency in ClassDescription. Thanks Nicolas Paez. - Issue 2882: recategorize Magnitude max: min:, Thanks Jaayer - Issue 2877: remove all methods that are equally defined in superclass. Thanks Marcus Denker. - Issue 2909: BehaviorTest is dependent on Morphic. Thanks Pavel Krivanek. - Issue 2884: TComparable. Thanks Jaayer Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] A thought about the fear of not knowing
Hi Pharoers, lurkers, users We repeat all over the same: we welcome you to participate and while we are cool and welcoming, you feel oh I cannot, I do not know, this is complex... You look at us like Gurus, but let us be clear, we are not, we are just common people that have a debugger, kids in the bed and good music in the background (for me Cool Jazz or Thrash Metal). Of course some parts of the system are ugly, buggy, britlle, messy... but less and less, more and more good abstractions are taking life AND First, we are all learners and newbie on something (at least the mortal among us) but to learn we should start somewhere Second, start small - we tag some bug entries as easy, give a try. - put a break point in the code - write a test - do something fun You will not fail, why? because either you do not find anything and there is no problem but you will learn something and you can pass to the next one. Or you find something and you got it :) We did that with marcus when we were squeak harvesters. There were a lot of things we could not get but we pass to the next. :) Now I browse bugs bugs and bugs and I can tell you that 85% of the bugs are terribly stupid. Even more. So focus on these ones :) Pharo is the system we (you and us) will build. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hudson
Lukas Renggli wrote: Did you check the README file of the distribution? http://github.com/renggli/builder Looks like just what I wanted, thanks. Lukas Renggli wrote: Also come to my ESUG presentation on Thursday titled Agile Seaside, I might show Hudson there :-) Cool, see you this week. Sean -- View this message in context: http://forum.world.st/Hudson-tp2531857p2532012.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
You mention something for viewing the log in-image. Dumb question: can it be left running and safely forgotten, or does it suffer under high load? Is there a way to view the log from outside of a running image? The latter is less important in proportion to the robustness of the in-image viewer. One thing that I often miss is DebugView; it would be really nice to find an equivalent on Linux. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Dale Henrichs [dhenr...@vmware.com] Sent: Wednesday, September 08, 2010 3:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] simpleLog in pharo? Stéphane Ducasse wrote: I will chekc I would like an object that represent wht is logged. do you have that? I do not want strings strings strings. On Sep 8, 2010, at 12:39 PM, Göran Krampe wrote: On 09/08/2010 11:45 AM, Stéphane Ducasse wrote: + 1 If someone could look at simpleLog (because we need to change this situation and get a good logging mechanism) We need much better infrastructure and we will build them. I wrote SimpleLog (in the Gjallar project) and feel free to pick/use it - it is small and maps easily to Syslog (I copied the levels that syslog has) and also has a syslog emitter which is *very* nice when you build Seaside apps and want to run multiple images with a load balancer in front for example. There are several logging libs but... well, I think SimpleLog strikes a nice balance of functionality and simplicity. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project In GLASS we have the ObjectLog ... the implementation is based upon RCQueue's (so that multiple vm's can concurrently add entries), but it is can be thought of as an OrderedCollection ObjectLogEntry instances: Object subclass: 'ObjectLogEntry' instVarNames: #( pid stamp label priority object tag) classVars: #( ObjectLog ObjectQueue) classInstVars: #() poolDictionaries: #[] inDictionary: '' category: 'Bootstrap-Gemstone' The pid and ObjectQueue are GemStone-specific ... - stamp DateAndTime - label String - priority Integer - object Object - tag Object GLASS has an ObjectLog component for viewing the object log ... inspector for in-image-viewing. There are currently 7 priorities defined: fatal - 1 error - 2 warn - 3 info - 4 debug - 5 trace - 6 transcript - 7 Yes Transcript messages are added to the ObjectLog ... very convenient ... Entries are added to the log via something like the following: (ObjectLogEntry info: 'label string' object: #( #hello 'world') addToLog. For GLASS I have a handful of subclasses of ObjectLogEntry that store things like a continuation and/or the url that caused the error... Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
The inspector is currently used to view the object log in the development vm...for large object logs it makes sense to filter the log before viewing. For external viewing I have a Seaside Component that allows one to filter and sort the object log entries as well as delete entries from the ObjectLog ... Since GemStone runs with multiple vms, you can use a separate vm to look at the shared object log ... .. The RCQueue (and OrderedCollections for that matter) in GemStone don't incur performance hits as the collection grows over time (unlike growing OrderedCollections in a normal client Smalltalk), but then GemStone was designed with very large collections in mind:)... GemStone was designed to handle collections and object graphs that can be larger than available memory, so you can forget about the object log until start running out of repository space (basically disk space) ... For the Pharo, I would think that the fact that an Object log could accumulate a whole lot of stuff is real limiting factor...there'd need to be a process that continuously pruned objects from the object log over time so a thread safe linked list might be a better choice for the Object log collection ... Dale Schwab,Wilhelm K wrote: You mention something for viewing the log in-image. Dumb question: can it be left running and safely forgotten, or does it suffer under high load? Is there a way to view the log from outside of a running image? The latter is less important in proportion to the robustness of the in-image viewer. One thing that I often miss is DebugView; it would be really nice to find an equivalent on Linux. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Dale Henrichs [dhenr...@vmware.com] Sent: Wednesday, September 08, 2010 3:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] simpleLog in pharo? Stéphane Ducasse wrote: I will chekc I would like an object that represent wht is logged. do you have that? I do not want strings strings strings. On Sep 8, 2010, at 12:39 PM, Göran Krampe wrote: On 09/08/2010 11:45 AM, Stéphane Ducasse wrote: + 1 If someone could look at simpleLog (because we need to change this situation and get a good logging mechanism) We need much better infrastructure and we will build them. I wrote SimpleLog (in the Gjallar project) and feel free to pick/use it - it is small and maps easily to Syslog (I copied the levels that syslog has) and also has a syslog emitter which is *very* nice when you build Seaside apps and want to run multiple images with a load balancer in front for example. There are several logging libs but... well, I think SimpleLog strikes a nice balance of functionality and simplicity. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project In GLASS we have the ObjectLog ... the implementation is based upon RCQueue's (so that multiple vm's can concurrently add entries), but it is can be thought of as an OrderedCollection ObjectLogEntry instances: Object subclass: 'ObjectLogEntry' instVarNames: #( pid stamp label priority object tag) classVars: #( ObjectLog ObjectQueue) classInstVars: #() poolDictionaries: #[] inDictionary: '' category: 'Bootstrap-Gemstone' The pid and ObjectQueue are GemStone-specific ... - stamp DateAndTime - label String - priority Integer - object Object - tag Object GLASS has an ObjectLog component for viewing the object log ... inspector for in-image-viewing. There are currently 7 priorities defined: fatal - 1 error - 2 warn - 3 info - 4 debug - 5 trace - 6 transcript - 7 Yes Transcript messages are added to the ObjectLog ... very convenient ... Entries are added to the log via something like the following: (ObjectLogEntry info: 'label string' object: #( #hello 'world') addToLog. For GLASS I have a handful of subclasses of ObjectLogEntry that store things like a continuation and/or the url that caused the error... Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
Re: [Pharo-project] [Metacello] Metacello ESUG 2010 topics for discussion/decision
Stef, I mention this in a Pharo thread but, In GemStone the Transcript entries are also added to the Object log, so the Object log has a long term collection of Transcript entries ... the key would be that Transcript entries should be automatically included in the logging scheme ... so that application code can continue to use the Transcript ... Dale stephane ducasse wrote: + 1 If someone could look at simpleLog (because we ned to change this situation) On Sep 8, 2010, at 10:09 AM, Simon Denier wrote: I have no idea whether this issue has been discussed before, and perhaps even solved, but is there an easy way to configure Metacello logging? Right now in Pharo, it goes into the Transcript, and consequently mixes with Compiler warning and other stuff. When we load ConfigurationOfMoose, there are so many items in the Transcript that we lost the first ones. We have to hack the Transcript to dump the interesting info into a file. On 7 sept. 2010, at 21:00, Dale Henrichs wrote: I've done a search through the Pharo and Metacello mailing lists (and my memory ... but only a little of that:) for open issues on Metacello and I've put together the following list: - #pharo1.0, #pharo1.1, #pharo1.2 attributes - Pharo1.0/Pharo1.1/Pharo1.2 version management - Metacello for updating pharo core configuration - ConfigurationOfOmniBrowser differences across versions - Pharo Metacello Universes (http://forum.world.st/ANN-Pharo-Metacello-Universes-td2313088.html#a2313088) (http://forum.world.st/ANN-Pharo-Metacello-Universes-td2313088i20.html#a2327571) (http://forum.world.st/Managing-Pharo-external-packages-with-Metacello-please-read-td2218629.html#a2218985) - AbstractMetacelloConfiguration (http://forum.world.st/How-can-I-load-metacello-without-OB-td2332353.html#a2335615) - default convention (http://forum.world.st/default-convention-td2316783.html#a2316783) - programmatic spec creation (http://forum.world.st/OO-Specs-td2328587.html#a2328587) - OS dependency (http://forum.world.st/Loading-platform-specific-code-td2318610.html#a2335791) - Gofer Project Loader (http://forum.world.st/ANN-Gofer-Project-Loader-1-0-BETA-td1596389i20.html#a2062909) These issues stand out for me, since I need some whiteboard time to wrap my brain around the requirements and then discuss potential solutions. I would hope that we can find time at ESUG for discussing these issues and making decisions on as many of the issues as possible (or at least plans of action)... If anyone else has issues that they think haven't been adequately covered, now would be a good time to bring up the issue (again) for discussion at ESUG ... if you aren't attending ESUG, refreshing the issue for consideration by those who are present is still a good idea. Dale -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
Dale Henrichs wrote: For the Pharo, I would think that the fact that an Object log could accumulate a whole lot of stuff is real limiting factor...there'd need to be a process that continuously pruned objects from the object log over time so a thread safe linked list might be a better choice for the Object log collection ... How about a circular queue, with removed entries written to a file. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] How to install Glorp
Hi Squeakers and Pharoers: Even when I saw several mails about the topic, I failed to install Glorp properly, on Squeak (4.1) and also on Pharo (4.1). No matter what method I try, or which Glorp .mcz, I allways get the attached error, referencing some weird oracle thing. I'm new to Glorp, I might be forgetting something obvious, but in any case, any help is appreciated Thanks. -- = Germán S. Arduino gsa @ arsol.net Twitter: garduino Arduino Software Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com = attachment: Syntax Error.png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] How to install Glorp
In pharo: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGlorpDBX'; load. and then (ConfigurationOfGlorpDBX project version: '1.2') load will install SqueakDBX as the database driver and Glorp-SqueakDBXDriver (ConfigurationOfGlorpDBX project version: '1.2') load: 'GlorpSqueakDBX Pool' will install SqueakDBX as the database driver and a Glorp-SqueakDBXDriver that acts as a connection pool :) (altought this only works in 1.0 right now) (ConfigurationOfGlorpDBX project version: '1.2') load: 'All with PostgreSQL native' will install the native postgresql driver Cheers Mariano BTW: you can find more info here (but it is outdated): http://www.squeakdbx.org/GLORP%20integration On Thu, Sep 9, 2010 at 12:19 AM, Germán Arduino gardu...@gmail.com wrote: Hi Squeakers and Pharoers: Even when I saw several mails about the topic, I failed to install Glorp properly, on Squeak (4.1) and also on Pharo (4.1). No matter what method I try, or which Glorp .mcz, I allways get the attached error, referencing some weird oracle thing. I'm new to Glorp, I might be forgetting something obvious, but in any case, any help is appreciated Thanks. -- = Germán S. Arduino gsa @ arsol.net Twitter: garduino Arduino Software Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A thought about the fear of not knowing
Kudos to you, it's always nice to see when programmers try to take the fear out of the equasion :) I think the terms experts and gurus should be completely abolished. It just strucks fear into the hearts of new programmers. What the heck is a guru? Or an expert? Someone who learnt a few nice little tricks over the years? Or knows a few kinks of a system? Well, I say nay! If there's a kink in a system it should be fixed, it shouldn't be a feeding ground for experts. And if someone knows a neat little trick, like a really fast implementation of an algorithm, what good is that when you actually don't need the speed in that place but think that readable code for example is much more important to you, so that maybe other people can understand and modify it. Implementing something is always a tradeoff between speed, stability, security and readability. There is not one perfect fits all solution to any one problem, which is why I don't think that experience really helps as much as people tend to believe. The most important thing for a programmer in my humble opinion is that he is good at learning. That includes being patient and persistent, being able to research things by using cryptic programmer's documentation and articles you find on Google. If you try long enough, you can make your implementation as fast, as stable, as secure or as readable as you need. The most important thing is to get it working, then you can think about making it better. And that is one hge strength of Pharo. The refactoring tools are awesome. There really is no need to fear doing something horribly wrong since you can refactor everything to your hearts content until it's just the way you want it to be semi-automagically. Experience can also really hinder you as a programmer. If you always do the same thing again because it worked good in the past, you will never find a better way of doing things. If everyone did that, we would still be in the stone age. Why do I need a metal hammer when a stone hammer works just fine? The only valid term I can think of would be a specialist. I have no idea how to write a device driver for example. That's something where experience is really helpful. But just because someone is really good at making device drivers doesn't mean he's good at making a game for example. So, he's not an expert programmer by any means, he's a specialist. You wouldn't let a dentist do brain surgery on you, would you? I don't think you can be an expert programmer. Programming is just too vast a topic. Computers are a second world. You can model the whole world in a computer. And just like you can't be an expert at every job on earth, you can't be a computer expert. It's just not possible with our brain's limited capacity. Chris On Wed, Sep 8, 2010 at 10:12 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi Pharoers, lurkers, users We repeat all over the same: we welcome you to participate and while we are cool and welcoming, you feel oh I cannot, I do not know, this is complex... You look at us like Gurus, but let us be clear, we are not, we are just common people that have a debugger, kids in the bed and good music in the background (for me Cool Jazz or Thrash Metal). Of course some parts of the system are ugly, buggy, britlle, messy... but less and less, more and more good abstractions are taking life AND First, we are all learners and newbie on something (at least the mortal among us) but to learn we should start somewhere Second, start small - we tag some bug entries as easy, give a try. - put a break point in the code - write a test - do something fun You will not fail, why? because either you do not find anything and there is no problem but you will learn something and you can pass to the next one. Or you find something and you got it :) We did that with marcus when we were squeak harvesters. There were a lot of things we could not get but we pass to the next. :) Now I browse bugs bugs and bugs and I can tell you that 85% of the bugs are terribly stupid. Even more. So focus on these ones :) Pharo is the system we (you and us) will build. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
On 09/08/2010 10:50 PM, Schwab,Wilhelm K wrote: You mention something for viewing the log in-image. Dumb question: can it be left running and safely forgotten, or does it suffer under high load? Is there a way to view the log from outside of a running image? The latter is less important in proportion to the robustness of the in-image viewer. One thing that I often miss is DebugView; it would be really nice to find an equivalent on Linux. Bill SimpleLog has a LogMorph, I didn't write it but it registers itself as an emitter. Not sure what it does if it is left running :) It could probably use a max backlog or something, if it doesn't have that already. Viewing the log from outside: There are two ways. First there is a logfile emitter - which writes to a log file and also does log file rotation after a max size etc. So you could always tail that file. Second is to use the syslog emitter - which IMHO is the best. That emitter uses syslog UDP standard messages to the local syslog port and then - on a normal linux box - your stuff will end up in the system log. From there you have TONS of tools. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
Göran, I think before we adopt anything, it should have the left running scenario addressed in some way. Pharo is supposed to be robust. That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees. On Windows, OutputDebugString() is probably good enough. Since I am doing everything I can to ditch said platform, I might not be the best person to ask. Certainly, it is where I would go for a live view, and a file-based log would then cover everything else - I think. On Linux, you mention lots of tools: any recommendations? Thanks! Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Göran Krampe [go...@krampe.se] Sent: Wednesday, September 08, 2010 6:57 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] simpleLog in pharo? On 09/08/2010 10:50 PM, Schwab,Wilhelm K wrote: You mention something for viewing the log in-image. Dumb question: can it be left running and safely forgotten, or does it suffer under high load? Is there a way to view the log from outside of a running image? The latter is less important in proportion to the robustness of the in-image viewer. One thing that I often miss is DebugView; it would be really nice to find an equivalent on Linux. Bill SimpleLog has a LogMorph, I didn't write it but it registers itself as an emitter. Not sure what it does if it is left running :) It could probably use a max backlog or something, if it doesn't have that already. Viewing the log from outside: There are two ways. First there is a logfile emitter - which writes to a log file and also does log file rotation after a max size etc. So you could always tail that file. Second is to use the syslog emitter - which IMHO is the best. That emitter uses syslog UDP standard messages to the local syslog port and then - on a normal linux box - your stuff will end up in the system log. From there you have TONS of tools. regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
Hi! On 09/09/2010 01:18 AM, Schwab,Wilhelm K wrote: Göran, I think before we adopt anything, it should have the left running scenario addressed in some way. Pharo is supposed to be robust. That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees. First - I did not bring this up, so feel free to fix any flaws you see/find :). The code base is very small. Secondly - my impression of Pharo so far is not really robust, and don't get me wrong here - it is not criticism, but my feeling every time I have used Pharo is that it is smack full of new stuff (completion, OB browsers etc etc) which quite often seems to break and also makes it painful to develop on my old trusty kinda slow Dell laptop. It seems to me that progress (new shiny stuff!) has been put in favor of robustness, which probably is why Pharo is attractive to a lot of people. Perhaps Pharo changed focus for next release? Sorry for that little rant, don't really mean anything with it, just curious to see if I am the only one with this feeling. On Windows, OutputDebugString() is probably good enough. Since I am doing everything I can to ditch said platform, I might not be the best person to ask. Certainly, it is where I would go for a live view, and a file-based log would then cover everything else - I think. On Linux, you mention lots of tools: any recommendations? No :). But there are lots of syslog related tools, just google it. :) regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
Phillipe wrote: Did you change your position towards #squeakToUtf8 and string concatenation (I didn't follow the entire previous thread)? Implicitly yes, but let's discuss this. You're saying you want WebClient without overrides but is this really what you mean? The only reason these methods are marked overrides is so that they don't kill your system if the methods themselves get added to the system at some point. For example, Grease currently adds extension methods for Collectionsorted but these methods are already in Squeak and while nothing harmful happens if you load Grease, unloading it will destroy several methods. As a consequence it is vastly advantageous to mark methods as overrides if they have even the slightest possibility to conflict (but of course if you'd rather have them straightforward extensions, I have no problems with that). As for integrating the changes itself, I think that we're talking two very different issues here. I suspect that the only objection to #squeakToUtf8 and #utf8ToSqueak is that they have Squeak in their name. I don't think you'd have any objection if they would've been called #utf8Encoded and #utf8Decoded. Which, honestly, is a childish attitude from my point of view. For string concatenation on the other hand, we're basically talking about dispersing a whole load of FUD about all the things that may go wrong. Fact is, nothing actually *does* go wrong with the change, but the change does fix situations that are *very* difficult to handle otherwise. One of the unfortunate realities of string concatenation is that it's very often used around error messages and logging, often in corner cases that aren't well tested, like: some impossible condition ifTrue:[ self log: 'Found impossible condition: ', foo. ]. The problem with these uses is that it's quite easy to forget some asString, or #printString (for example, if you generally had expected foo to be a string but in the impossible condition it's actually nil) and when you hit the condition your logging screws up and instead of getting informed about the impossible condition the program quits due to the error. In fact, I'm willing to bet that there's at least one bug in Pharo and/or Seaside which is the result of erroneous string concatenation of this kind. It's just very easy to get wrong. The other relevant bit about this change is that it's entirely type-safe. I.e., the return type does not depend on the argument, the return type is always a string. That means that the change does *not* introduce failures down the road due to type violations. It *does* mean that if you have a bug in your code you might print a SomethingOrOther when you didn't mean to, but unless you're the kind of person who believes that a program that doesn't raise an error must be obviously correct, this makes little difference. The only difference it makes is that your program will not abort when the *intention* is so utterly obvious. Put differently, the change adds nothing but robustness to the system. There is really no data to back up the FUD about all the changes that may go wrong, but from my experience there is ample evidence to show that logging and error handling involving string concatenation is highly susceptible to this kind of problem and generally not very well tested and difficult to QA. And the major use of string concatenation is right in these areas. Last but not least, programming is about efficiency. Why would you waste your time in typing 'The result is: ', x printString when you could just type 'The result is: ', x and spare the time to write all the extra characters? Do you realize how much time you've wasted sprinkling all those #printString and #asString around WebClient? Cheers, - Andreas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
El mié, 08-09-2010 a las 19:27 -0700, Andreas Raab escribió: It is amazing how square-minded you are. All this diatribe was nothing but to defend the current state of the code you write. Phillipe wrote: Did you change your position towards #squeakToUtf8 and string concatenation (I didn't follow the entire previous thread)? Implicitly yes, but let's discuss this. You're saying you want WebClient without overrides but is this really what you mean? The only reason these methods are marked overrides is so that they don't kill your system if the methods themselves get added to the system at some point. For example, Grease currently adds extension methods for Collectionsorted but these methods are already in Squeak and while nothing harmful happens if you load Grease, unloading it will destroy several methods. As a consequence it is vastly advantageous to mark methods as overrides if they have even the slightest possibility to conflict (but of course if you'd rather have them straightforward extensions, I have no problems with that). So now overrides are encouraged? As for integrating the changes itself, I think that we're talking two very different issues here. I suspect that the only objection to #squeakToUtf8 and #utf8ToSqueak is that they have Squeak in their name. I don't think you'd have any objection if they would've been called #utf8Encoded and #utf8Decoded. Which, honestly, is a childish attitude from my point of view. Well then lets rename withBlanksTrimmed to, lets say, windowsWithBlankTrimmed, or maybe lispWithBlankTrimmed, or better yet, asdfAsdfASDF. The name must be right, no matter what you personally think. For string concatenation on the other hand, we're basically talking about dispersing a whole load of FUD about all the things that may go wrong. Fact is, nothing actually *does* go wrong with the change, but the change does fix situations that are *very* difficult to handle otherwise. One of the unfortunate realities of string concatenation is that it's very often used around error messages and logging, often in corner cases that aren't well tested, like: some impossible condition ifTrue:[ self log: 'Found impossible condition: ', foo. ]. Maybe in practice happens. That is not a excuse to put the burden in the environment and let the software that relies in wrong code remain unfixed. If some package hits the error, the right thing is to fix the package, not to put trash in the environment just in case. This promotes mean software The problem with these uses is that it's quite easy to forget some asString, or #printString (for example, if you generally had expected foo to be a string but in the impossible condition it's actually nil) and when you hit the condition your logging screws up and instead of getting informed about the impossible condition the program quits due to the error. In fact, I'm willing to bet that there's at least one bug in Pharo and/or Seaside which is the result of erroneous string concatenation of this kind. It's just very easy to get wrong. Idem. If that is the case, then Seaside must be corrected. The other relevant bit about this change is that it's entirely type-safe. I.e., the return type does not depend on the argument, the return type is always a string. That means that the change does *not* introduce failures down the road due to type violations. It *does* mean that if you have a bug in your code you might print a SomethingOrOther when you didn't mean to, but unless you're the kind of person who believes that a program that doesn't raise an error must be obviously correct, this makes little difference. The only difference it makes is that your program will not abort when the *intention* is so utterly obvious. Wrong, I prefer it abort loudly so I now that there is something wrong in the package and I can fix it, not hide it because the environment somehow worked around it. Put differently, the change adds nothing but robustness to the system. There is really no data to back up the FUD about all the changes that may go wrong, but from my experience there is ample evidence to show that logging and error handling involving string concatenation is highly susceptible to this kind of problem and generally not very well tested and difficult to QA. And the major use of string concatenation is right in these areas. So your experience is real data to back up your claims but others isn't. BS! Last but not least, programming is about efficiency. Umm, wasn't Smalltalk about intention-reveling code. Wasn't adviced everytime that premature optimization is evil. Since when Smalltalk was about efficiency. Isn't C programming. Why would you waste your time in typing 'The result is: ', x printString when you could just type 'The result is: ', x and spare the time to write all the extra characters? Do you realize how much time you've
