- Pharo-dev - lists.pharo.org

[Pharo-project] i know esug just started...but some kind soul can please revive squeaksource
by Fernando olivero Sept. 13, 2010

Sept. 13, 2010

thanks, Fernando

1 0

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 84
by Ralph Boland Sept. 13, 2010

Sept. 13, 2010

> Hi, i don't know why things are done the way they are... > Is your question how the exception mechanism works, or why it is > needed to be done with an exception? as opposed to say doing it > some other way? > The direct answer to your question is that given it is implemented in > terms of exceptions, the signal is needed to trigger the > defaultAction, or to allow someone higher up in the stack to trap it > and redirect the notification. > cheers, > Mike I am no expert on Exceptions but I do understand this. What I don't understand is WHY ProgressInitiationException is used and why a signal is sent to its instance to get the ball rolling. Could not SystemProgressMorph be modified to handle this? Alternatively, could not some other new (non-exception) class handle the logic where an instance of that class is created and gets the ball rolling without sending a signal to itself? For me, currently, this is the more intuitive way to do things. Why use signals when they are not needed? (Or are they needed for some reason unknown to me?) The modifications I am planning to make to the ProgressDisplay package look easier if I get rid of the signal handling. But I don't know what I will be breaking or what functionality will be lost if I get rid of the signal handling. So I need to know WHY? Regards, Ralph Boland > On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland <rpboland(a)gmail.com> wrote: > > I posted the following earlier to the Squeak list but didn't get a responce. > > Hopefully someone on the Pharo list can help me. ?I need this information > > so I can make some planned changes to the ProgressDisplay package I released > > a while back. > > > > ----------------------------------------------------------------------------------------------------------------- > > > > A SystemProgressMorph is used to display progress while some computation > > is being done. ?Furthermore the progress bars can be stacked to show progress > > of component computations within a computation. > > This I understand and understand most of the code. > > But not All. > > What I have trouble with is understanding why a ProgressInitiationException > > is needed. ?In particular, String>>displayProgressAt:from:to:during: > > does: > > > > ProgressInitiationException > > display: self > > at: aPoint > > from: minVal > > to: maxVal > > during: workBlock. > > > > > > This method sets a few variables and then does: > > > > ^self signal > > > > This signal is caught where upon a SystemProgressMorph is started or > > extended with > > an additional progress bar. > > > > But I don't understand why sending a signal to a ProgressInitiationException > > is needed to get the ball rolling, > > > > Can someone please explain why things are done the way they are? > > > > > > Regards, > > > > Ralph Boland

3 4

[Pharo-project] Alien and multi-threading
by Noury Bouraqadi Sept. 12, 2010

Sept. 12, 2010

Hi, Is there any possibility for multi-threading with Alien? Noury @ ESUG 2010 - Barcelona :-) --- 18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, Spain. http://www.esug.org/Conferences/2010

3 2

[Pharo-project] [ANN] Seaside 3.0 released
by Michael Davies Sept. 12, 2010

Sept. 12, 2010

The Seaside core developers are pleased to announce the release of Seaside 3.0 - see http://seaside.st/seaside30 for more information. The changes in 3.0 are intended to make using and extending Seaside faster and easier. Useful Links: Full Release Announcement http://seaside.st/seaside30 Seaside 3.0 Detailed Release Notes http://seaside.st/community/development/seaside30 Seaside One-Click Experience 3.0 (runs with one-click on Mac, Windows and Linux) http://www.seaside.st/distributions/Seaside-3.0-final.app.zip Seaside 3.0 Developer Image 3.0 (for Pharo developers) http://www.seaside.st/distributions/Seaside-3.0-final.zip Seaside 3.0 SqueakSource Repository http://www.squeaksource.com/Seaside30.html

1 0

[Pharo-project] [update 1.2] #12140
by Marcus Denker Sept. 12, 2010

Sept. 12, 2010

12140 ----- Issue 2735: Null Styler for PluggableTextMorph Issue 2960: Fix size for the OverRowMorph in the Browser -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Mark and space parity
by Schwab,Wilhelm K Sept. 12, 2010

Sept. 12, 2010

Tony, I *almost* understand that, and greatly appreciate your reply. Compiling a new vm is getting to be routine, mostly because I find its diagnostic output to be far less than I typically want when sorting out a problem. Certainly the Windows vm goes out of its way to fail on valid settings and should be changed to allow parity values 3 and 4; the Linux vm might also benefit from relaxing its checks. The interesting part is that I don't need to send to the device, only read from it. If my notes are correct, it is 7S2. Gary, re programming by barcode, are you thinking that I might be able to get the scanner to use different settings? I wondered about that last night. There is a fairly extensive book full of barcodes that I believe are for changing the scanner's behavior. In your experience, are such changes stored in persistent store (flash, eprom, etc.), or are they transient such that they typically have to be restored each time the scanner loses power? If I can get it to use something friendly to the vm and stay that way, that might be a good solution. Bill ________________________________________ From: Tony Garnock-Jones [tonyg(a)lshift.net] Sent: Saturday, September 11, 2010 1:44 PM To: The general-purpose Squeak developers list Cc: Schwab,Wilhelm K; vm-dev(a)lists.squeakfoundation.org; Pharo-project(a)lists.gforge.inria.fr Subject: Re: [squeak-dev] Mark and space parity Hi Bill, Based on http://www.lothosoft.ch/thomas/libmip/markspaceparity.php, it looks like you're set if you need 7S1. If you need 8S1, however, the options for linux are - flip between 8N1 and 8E1 depending on the byte to send, or - use the undocumented CMSPAR flag. Given that the SerialPort class in Squeak uses 0, 1, 2 for no, even and odd parity respectively, and the sqUnixSerial.c driver doesn't support any other kinds of parity specification (see the table parityTypeDecode), ruling out the use of CMSPAR, your only option (aside from modifying the SerialPlugin or writing your own) is to flip between 8N1 and 8E1 for each byte. Unfortunately it doesn't look like there's a way to get at tcsetattr without also doing an open, so there goes that idea as well. In summary: 7S1 ought to be OK (use 8N1 with a cleared 8th bit), but I suspect that 8S1 is out of reach without changes to the SerialPlugin. Regards, Tony On 11/09/2010 09:42, Schwab,Wilhelm K wrote: > I ran across a device (barcode scanner) that uses space parity and dug into vm code to see if it was indeed going to be a problem. This is not a debate on whether or not the designers of the device could have chosen something else: clearly they should have. The question is whether our vms should be able to communicate with it, and they should where possible. > > It is not clear whether Linux even supports space parity, though there are hints that recent kernels do so. Windows certainly does support it. Have any of you made the required changes and had success with it? On which operating system(s)? > > Bill > > >

2 2

[Pharo-project] [update 1.2] #12139
by Marcus Denker Sept. 12, 2010

Sept. 12, 2010

12139 ----- Issue 2953: Fixing bug with select in paragraphEditor Issue 2956: remvove #bigDisplay and collapsewinInPlace Issue 2950: ChangeList errors Issue 2954: Accepting method with undefined variable -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] pharo tests
by Linus De Meyere Sept. 12, 2010

Sept. 12, 2010

Pharo dev's, I'm lurking around the Pharo project for a while now. As I wanted to get some hands-on experience with Pharo I thought it was a good idea to fix an easy bug and see how it goes. The wiki page on how to contribute, and the two screen casts are a great help for newbies like me. Nevertheless, I was wondering if there was an important aspect missing from these instructions: what about tests? I know there is a hudson server running the tests regularly, but I wonder if many people are paying attention to it. Shouldn't there be some instruction on how to add tests for new functionally (or even for a bugfix, if tests weren't already there), and then some instructions on how to run all (or some subset of) the tests to get confidence you didn't broke anything with your changes? How do you, experienced Pharo contributors, go about this? Do you guys run these tests before every check-in? Are there many tests to run? Are there some guidelines to writing tests when contributing to Pharo? Thx, Linus

2 1

[Pharo-project] [update 1.1] #11414
by Marcus Denker Sept. 12, 2010

Sept. 12, 2010

11414 ----- - Call releaseClean - Set version number to 1.1.1 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] WebClient License Update
by Andreas Raab Sept. 12, 2010

Sept. 12, 2010

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). Cheers, - Andreas

11 19