- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SqueakMap code into Pharo?

by Lukas Renggli

> How do I load code that is in SqueakMap into a Pharo Image? You go to the SqueakMap website (http://map1.squeakfoundation.org/) navigate to the project, download the release and drag&drop it into the Pharo image. > Specifically I'm interested in Sixx and SoapCore but it would be good to > know if there is a general way to load code from SqueakMap into a Pharo > image. Presumably the code from SqueakMap outdated, you might also want to search on SqueakSource. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 12, 2009

[Pharo-project] SqueakMap code into Pharo?

by Monty Kamath

How do I load code that is in SqueakMap into a Pharo Image? Specifically I'm interested in Sixx and SoapCore but it would be good to know if there is a general way to load code from SqueakMap into a Pharo image. Thanks, Monty -- View this message in context: http://n2.nabble.com/SqueakMap-code-into-Pharo-tp4157808p4157808.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 12, 2009

Re: [Pharo-project] [update 1.1] #11097

by Mariano Martinez Peck

On Sat, Dec 12, 2009 at 3:59 PM, Marcus Denker <denker(a)acm.org> wrote: > > On Dec 12, 2009, at 3:56 PM, Mariano Martinez Peck wrote: > > > > > > > On Sat, Dec 12, 2009 at 3:53 PM, Marcus Denker <denker(a)acm.org> wrote: > > 11097 > > ----- > > > > Issue 1577: clean isSpecialWriteBinding (again) > > Issue 1585: More random dead code removal (76 unsent method removed) > > > > > > Marcus, when you this kind of removal (unsent methods), do you check also > on Dev and Web image? or just core ? > > > right now I only check the core... :-) > > But the methods removed are of the kind that they really should not be part > of a public API.... > IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests. Cheers, Mariano > And should we remove too much: bringing back is simple. > > Marcus > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 12, 2009

[Pharo-project] The method trailer format

by Igor Stasenko

Here is my proposal for changing the method trailer in order to be able to encode various stuff to trailer. Any corrections, suggestions are welcome. The kind of compiled method trailer is determined by the last byte of compiled method. The format is following: "2rkkkkkkdd" where 'k' bits stands for 'kind' , allowing totally 2^6 different kinds of method trailer and 'd' bits is data. The following is description of defined trailer kinds: k = 000000, dd = 00 method has no trailer, and total trailer size bytes is 1 (just for last byte) k = 000001, method has cleared trailer (it was set to something else, but then cleared) dd+1 determines the number of bytes for size field, and size is a total length of trailer bytes So a total length of trailer is: 1 + (dd + 1) + size k = 000010 the trailer contains a list of method temp names, compressed using qCompress: method. dd+1 determines the number of bytes for size field, and size is a number of bytes of compressed buffer. So a total length of trailer is: 1 + (dd + 1) + size k = 000011 the trailer contains a list of method temp names, compressed using GZIP compression method. dd+1 determines the number of bytes for size field, and size is a number of bytes of compressed buffer So a total length of trailer is: 1 + (dd + 1) + size k = 000100 the trailer indicates , that method source is determined by a class + selector where it is installed to. Trailer size = 1. k = 000101 the trailer indicates , that method source is determined by a class + some ByteString identifier. dd+1 determines the number of bytes for size field, denoting the length of ByteString identifier. A total length of trailer is: 1 + (dd + 1) + size k = 000110 the trailer contains an utf-8 encoded method source code, compressed using qCompress: method. dd+1 determines the number of bytes for size field, denoting the length of compressed buffer A total length of trailer is: 1 + (dd + 1) + size k = 000111 the trailer contains an utf-8 encoded method source code, comressed using GZIP dd+1 determines the number of bytes for size field, denoting the length of compressed buffer A total length of trailer is: 1 + (dd + 1) + size k = 111111 the trailer is encoded source pointer. Total trailer size is 4-bytes (this is backwards compatible with most of currently existing compiled methods) k = 111110 the trailer is encoded source pointer. Total trailer size is 5-bytes k = 111101 the trailer is encoded source pointer. Total trailer size is 6-bytes k = 111100 the trailer is encoded source pointer. Total trailer size is 7-bytes k = 111011 the trailer is encoded source pointer. Total trailer size is 8-bytes -- Best regards, Igor Stasenko AKA sig.

Dec. 12, 2009

Re: [Pharo-project] [update 1.1] #11097

by Marcus Denker

On Dec 12, 2009, at 3:56 PM, Mariano Martinez Peck wrote: > > > On Sat, Dec 12, 2009 at 3:53 PM, Marcus Denker <denker(a)acm.org> wrote: > 11097 > ----- > > Issue 1577: clean isSpecialWriteBinding (again) > Issue 1585: More random dead code removal (76 unsent method removed) > > > Marcus, when you this kind of removal (unsent methods), do you check also on Dev and Web image? or just core ? > right now I only check the core... :-) But the methods removed are of the kind that they really should not be part of a public API.... And should we remove too much: bringing back is simple. Marcus

Dec. 12, 2009

Re: [Pharo-project] [update 1.1] #11097

by Mariano Martinez Peck

On Sat, Dec 12, 2009 at 3:53 PM, Marcus Denker <denker(a)acm.org> wrote: > 11097 > ----- > > Issue 1577: clean isSpecialWriteBinding (again) > Issue 1585: More random dead code removal (76 unsent method removed) > > Marcus, when you this kind of removal (unsent methods), do you check also on Dev and Web image? or just core ? Cheers, Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 12, 2009

[Pharo-project] [update 1.1] #11097

by Marcus Denker

11097 ----- Issue 1577: clean isSpecialWriteBinding (again) Issue 1585: More random dead code removal (76 unsent method removed)

Dec. 12, 2009

[Pharo-project] [update 1.1] #11096

by Marcus Denker

11096 ----- Issue 1584: ifEmpty: should not return nil if not empty Issue 1588: remove Compressed Sources Issue 1586: clean FileList Issue 1587: clean visitFutureNode:

Dec. 12, 2009

Re: [Pharo-project] MetaSource (was: A centralized repository (Going a step forward Gofer and Metacello))

by Laval Jannik

Hi, It seems to be cool :) But you said it is a SqueakSource successor. Can you explain what are the new features ? Thank you, Cheers Jannik On Dec 7, 2009, at 15:57 , Torsten Bergmann wrote: > Esteban Lorenzano wrote: >> I will start work on a first version of tools needed > > Have a look at MetaSource, started as a SqueakSource > successor based on newer Squeak/Pharo/Seaside with > possible Metacello integration in the future. > > http://www.squeaksource.com/MetaSource > > Attached is a screenshot. > > Use one of Damiens latest Pharo dev-images and use > the package "MetaSource-ImageBuilder" to load all. > (it loads Seaside, FFI, Widgetbox, MetaSource ...) > and prepares a full image with the webapp ready to start. > > It was discussed offlist and progress is very slow but > could be a start. Outcome of the offlist discussion was to > (maybe) wait until the next Monticello version is out > and a stable Metacello is ready... > > Bye > T. > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > <metasource.png>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 12, 2009

[Pharo-project] Where's the beef? (Was: Re: [Newbies] [semi-OT] (fwd) Re: What Killed Smalltalk?)

by Lawson English

To continue and extend my rant in response to this thread, here are examples of Books I'd Like to See for Squeak/Pharo: Books like these: http://www.greenteapress.com/semaphores/downey05semaphores.pdf http://www.greenteapress.com/compmod/ http://beej.us/guide/bgnet/ Articles like these: http://www.amk.ca/python/howto/sockets/ http://nehe.gamedev.net/ http://rubylearning.com/satishtalim/ruby_threads.html and http://rubylearning.com/satishtalim/ruby_socket_programming.html http://www.boddie.org.uk/python/XML_intro.html interfaces like these: http://www.spiderland.org/ etc. Without these kinds of materials available specifically oriented towards squeak/pharo use, your average beginning/intermediate programmer is NOT going to find squeak/pharo all that attractive. Another area lacking (where squeak should shine above all others) is in the voice-over demo/tutorial on youtube arena. A youtube video of VNC-based pair-programming on a beginning/intermediate level problem using squeak could be very compelling, I think. This would be the poor man's version of my idea about a web-cast of a live pair-programming session. Actually doing the live webcast, complete with mutli-channel chat/feedback/comments/questions and then making it available the way Metanomics interviews are, would be a very good teaching/marketing tool for Smalltalk. A primitive example of this is found about 2 minutes into this science friday video: http://www.youtube.com/watch?v=4fWPwOLJFA8 People have devised web-page playback of the video synced with the local chat discussion without the distracting superposition of the text chat on top of the video image, which could be very useful in a teachingseminar context, I believe. Lawson Lawson English wrote: > Steve Wessels wrote: >> That's right. Smalltalk hasn't died. I am fortunate enough to be >> part of a team developing financial software for many years using >> Smalltalk. >> >> People have predicted Smalltalk's death about as often as Apple's death. >> >> I think comparisons between Smalltalk and Java have to take marketing >> into account. >> >> Paying Smalltalk work is harder to find. Here's an interesting >> twist. Companies looking for skilled Object Oriented developers, if >> they understand what they need, will seek programmers with Smalltalk >> experience. >> >> > > Speaking as a long-term script kiddie who likes to collect languages, > I can tell you that the main reason(s) why *I* find Smalltalk > difficult to use involve(s): lack of documentation, lack of > well-documented example code, lack of compsci teaching materials > written with Smalltalk for the example code, etc. Notice a trend? > > Smalltalk may have been designed to be easy to learn and use, but it > has never been adopted by the pedagogical community of teachers and > how-to book-writers, so naturally new programmers (from whom > experienced programmers grow) are never attracted to it. > > The main issue is lack of ways for new programmers (experienced in > other languages or otherwise) to learn not just the syntax of the > language, but how to DO stuff with it. > > E.G.: I can't grab the Unix Programming or Unix Network Programming > books by Stevens and work through Smalltalk equivalents of the example > code. There's no Data Structures in Smalltalk books, nor Algorithm > Analysis in Smalltalk books, nor build your own virtual world from > scratch using Smalltalk and OpenGL, or Game AI in Smalltalk, or... > There IS a Numerical Methods book in Smalltalk, but that's hardly > beginner/intermediate level, IMHO. > > You get the idea. All the reference material for Smalltalk is geared > for complete beginners, or for people who are exceedingly experienced. > No middle ground. > > > And some of the most interesting (sounding) aspects of Smalltalk, such > as the Teatime architecture, are hardly covered in ways that relative > newcomers can understand (speaking as a relative newcomer with a 2 > year AAS degree and a couple decades intermittent experience > programming). > > Smalltalk (e.g. Squeak) may not be fast enough to be used in high-end > production implementations, but surely it could be the > language-of-choice for learning new aspects of compsci and > programming. After all, many of these "new aspects" of compsci and > programming were originally developed/matured using Smalltalk. Why > should people have to go to a less versatile language in order to > actually learn to use the results of Smalltalk-based research? > > > > Lawson > _______________________________________________ > Beginners mailing list > Beginners(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners >

Dec. 12, 2009