- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14335
by Marcus Denker Feb. 17, 2012

Feb. 17, 2012

14335 ----- Issue 5299: Yet another Zn update http://code.google.com/p/pharo/issues/detail?id=5299 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 1.4] #14334
by Marcus Denker Feb. 17, 2012

Feb. 17, 2012

14334 ----- Issue 5307: Debugger improvement http://code.google.com/p/pharo/issues/detail?id=5307 Issue 5305: cannot filein an entire file http://code.google.com/p/pharo/issues/detail?id=5305 Issue 5292: FileDialogWindow(Object)>>doesNotUnderstand: #directoriesFor: http://code.google.com/p/pharo/issues/detail?id=5292 Issue 5306: Dont deadlock Morphs http://code.google.com/p/pharo/issues/detail?id=5306 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] setsockopt: No,buffer space available
by Philippe Marschall Feb. 17, 2012

Feb. 17, 2012

Hi I have some code that runs a protocol on consisting of 8k packets over TCP. This works fantastically well on Linux. However on Mac OS I get a lot of failed request. Investigating further I found the following error log: 16.02.12 18:44:12.485 [0x0-0x95095].com.squeak.Cog: setsockopt: No buffer space available After some more investigation I found out that I do set SO_SNDBUF and SO_RCVBUF to 8192 (remember 8k packets) but these calls fail. That's on Mac OS 10.7, I'm not sure but the way I remember it the code was working on Mac OS 10.6 Cheers Philippe

2 1

Re: [Pharo-project] [update 1.3] #13321
by Marcus Denker Feb. 17, 2012

Feb. 17, 2012

On Feb 16, 2012, at 11:05 PM, Helene Bilbo wrote: > where can you find this version? > on the website the newest version is 13315 and on Jenkins 13320. > jenkins should have updated automatically... I will check why not. -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] Is the plan to replace FileStream by FSStream?
by Henrik Johansen Feb. 17, 2012

Feb. 17, 2012

On Feb 16, 2012, at 8:07 PM, Henrik Johansen wrote: > > On Feb 16, 2012, at 6:45 PM, Luc Fabresse wrote: > >> Hi, >> >> reading this: http://code.google.com/p/pharo/issues/detail?id=5303 >> I wonder if the plan is to replace FileStream by FSStream? >> >> #Luc >> > My vote would be no. > http://forum.world.st/pharo-vision-tp4340345p4342871.html > http://forum.world.st/pharo-vision-tp4340345p4341445.html > > You'd be stuck chasing bugs trying to bring FSFileStreams up to pair with the normal FileStreams for many, many releases. > I'd rather try one of the approaches mentioned in the 2nd link, setting StandardFileStream as the default plugged-in stream implementation, so you could rewrite the path API manipulation in your code independent of the stream/file reading/writing. > > Cheers, > Henry Let me put it another way: FS is a really good, no, compared to what we have now, - excellent - API for specifying paths. 1) If we *ever* want people to start using it with existing code though, we need to decouple the task of rewriting path creation from that of also rewriting the code using streams opened on said paths. 2) By making the stream implementation used by FS pluggable you: - Reduce the size of FS core, making it more focused on the actual FileSystem manipulation/querying part of the framework. - Can still provide an ANSI stream implementation for people writing new, portable code. - Solve #1, by letting existing users continue to use their, however flawed, existing stream implementations. Cheers, Henry

2 2

[Pharo-project] Opening...
by S Krish Feb. 17, 2012

Feb. 17, 2012

http://ie.linkedin.com/jobs/jobs-Smalltalk-Senior-Software-2124837 Just in case I can put it in perspective.. . This is a VA App of about 3 million lines of code.. Ported to Java and now live. The VA work is now to maintain and sustain it till Java can get its handle over all the major implementations over the years ahead. That said it is great base, built over the last 19 years from a Enfin Smalltalk base, comparable to Kapital.. though a different domain that is vast and complex financial market. Fun to master the domain and its implementation therein in Smalltalk. -Skrish

2 2

[Pharo-project] [update 1.3] #13321
by Marcus Denker Feb. 16, 2012

Feb. 16, 2012

13321 ----- Issue 5228: MorphTreeMorph hide last element when horizontal scrollbar is shown http://code.google.com/p/pharo/issues/detail?id=5228 Issue 4840: Schedule>>between:and:do can iterate over the wrong dates. http://code.google.com/p/pharo/issues/detail?id=4840 -- Marcus Denker -- http://marcusdenker.de

3 2

[Pharo-project] TabbedPane Class/ Package / Workspace browsers
by S Krish Feb. 16, 2012

Feb. 16, 2012

Just this quick n usable prototype.. ? Any comments of its utility.. I for one would rather prefer having everything navigable from one Tabbed Pane.. Panes capable of rendering about every window of the basic tools of Pharo.. workspace, Finder, ScriptManager, possibly Transcript as a console collapsible as reqd Akin to the eclipse but not really that intensively single windowed.. there are uses for spawning separate windows..

4 5

[Pharo-project] Is the plan to replace FileStream by FSStream?
by Luc Fabresse Feb. 16, 2012

Feb. 16, 2012

Hi, reading this: http://code.google.com/p/pharo/issues/detail?id=5303 I wonder if the plan is to replace FileStream by FSStream? #Luc

3 3

Re: [Pharo-project] annoying press "ok" when running tests (not headless)
by Henrik Johansen Feb. 16, 2012

Feb. 16, 2012

On Feb 16, 2012, at 2:20 PM, Henrik Johansen wrote: > > On Feb 16, 2012, at 2:05 PM, Igor Stasenko wrote: > >> On 16 February 2012 13:53, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On Feb 16, 2012, at 12:52 PM, Igor Stasenko wrote: >>> >>> Can't say that i like this "pulling" model, querying theme over and over >>> again.. >>> I think it would be much nicer to actually use push model, i.e. let >>> theme push a props to widget, >>> >>> >>> IIRC from what Gary has posted, it was done that way to easily: >>> 1) have morphs respond to a theme change. (since they fetch values from the >>> theme each draw cycle) >>> 2) not have to hold the state in each individual morph. >>> >>> Now: >>> 1) should be much easier/cleaner to do using Announcements. >>> 2) is still an issue. However, since most calls create new objects (the >>> different Theme colors are usually created from scratch each call, for >>> instance), and writing it to include caching also leads to ugly code, it >>> might not be as bad. >>> >>> As for adding values for new widgets >>> - Why do you need a specific label color for growl rather than use the >>> default theme label color? >>> - If you really do, why not use one of the base label colors from the theme >>> (as presented by the facade), and then modify it accordingly instead? >>> (#lighter, #darker, etc) >>> >> Yes, status-quo. I agree, that most of the time >> widgets should use base set of colors (what they are . btw?) provided by theme. >> But it is not always possible, since some widget could have absolutely >> unique properties, >> which cannot be synthesized from any other properties. >> For example, speaking about Growl morph, it could have settings >> controlled by theme like: >> - in what corner of screen to pop up >> - after how many seconds it should start to fade >> - should it fade or just disappear immediately >> - and how long it should fade. > Again, if they are fully unique, then why are you consulting a Theme in the first place? > By which I mean; A Theme provides an API to a consistent look and feel (color scheme, roundness of widgets etc). As for what you specified, either that IS specific to the Growl Morph, and should therefore be contained in the growl morph (with appropriate settings), or you encase in the theme settings related to generic *pop-up* behavior. I just don't see the use of providing styling info like #growlLabelColor from a *Theme*, for the same reason I don't think #debuggerScrollbarThickness would be an appropriate thing to ask of a Theme. Cheers, Henry

1 0