- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Popularity or not of smalltalk?

by Casimiro de Almeida Barreto

Em 06-12-2010 13:38, csrabak(a)bol.com.br escreveu: > James, > > The point of your post will surely be answered by other, and I'm sure you'll find good stuff in STIC and ESUG websites. > > However, the purpose of yours surprises me: why do you think that having "a popular and great IDE company" "supporting" Smalltalk is of any help? In the past there were "big companies" "supporting" smalltalk and the result was no good. If one reads some of smalltalk history he'll see a spectacle of greed & other bad doings and nasty mistakes by corporations. The biggest problem with smalltalk itself was that it was far ahead its time. Now it's not. Further than that, when one sees things like CogVM coming to life (which enhances performance of applications) and things being developed in seaside and related tools (pier, magritte, etc) it becomes clear the advantages of adopting smalltalk, despite some issues are still recurrent like: the lack of a "foundation classes" definition (thus much of trunk/pharo/etc changing overtime and requiring constant attention and maintenance by developers) and lack of documentation (which is consequence of first issue). > Decoupling the Smalltalk environment from the "IDE" will make a Frankenstein which will make the acronym 'IDE' look like an oxymoron... There are some implementations decoupled from IDEs. But in the end of the day everybody needs a browser, an inspector, a debugger, a workspace, a Transcript, etc... And nobody really needs to develop a "windows native", "X Windows native", "aqua/OS-X/iOS native" version of the same application (at least not that frequently). Anyways, if the intention is running an application with the "native interface" deactivated it's always possible to execute smalltalk headless. Regards CdAB > Regards, > > -- > Cesar Rabak > > Em 06/12/2010 03:51, James Ladd < james_ladd(a)hotmail.com > escreveu: > > > While pleading for Smalltalk support with a developer from a popular and great IDE company, I got the > > following response (below) > > > > Is there anything I can do/show to prove or disprove the popularity of Smalltalk? > > > > Rgs, James. > > > > > >>> Hello James. >>> About Smalltalk plugin. Weel, Iâm not sure Smalltalk has a big audience now. Iâve never heard about commercial products based on Smalltalk. >>> Here, some statistics http://langpop.com/ >

Dec. 8, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by StÃ©phane Ducasse

On Dec 8, 2010, at 9:26 AM, Sven Van Caekenberghe wrote: > Norbert, > > Thanks for you interest. > > On 07 Dec 2010, at 21:14, Norbert Hartl wrote: > >> I scanned the code a few days ago. I tried an initial port to gemstone. There are quite a few things to do. After discovering that there are really big changes from version to version and the existence of classes with suffixes Old and New made me stop the effort. I'm really missing a usable http client in gemstone but it seemed to be very hard to keep up with the port. > > This should be much better now: the whole confusion is now gone (the 'Old' categories and classes were moved into a separate MC package that should not be loaded unless you want to do historical research; the 'New' has been removed from existing categories). Please have another look. > > I assume that you have read the overview and getting started pages (http://homepage.mac.com/svc/Zinc-HTTP-Components) > > The category 'Zinc-HTTP-Core' contains a object model of the key building blocks of the HTTP protocol. Except for learning and teaching, this is not useful on itself. Building on top of the core are the classes in 'Zinc-HTTP-Server' for various clients and servers. The category 'Zinc-HTTP-Support' contains helpers for the implementation, many of which can be considered portability enablers (much like Seaside has them). > > Now, why is there not just one good client, why are there 4 different ones ? > > Because different users have different requirements, because each of them has different features, complexity and above all, a different interface. Part of this is also a search for the ideal API. > > ZnClient is the simplest one: some class methods to fire off one shot requests. > > ZnFixedClient is useful to connect to a single server and reuse the connection for multiple requests, like with a web services API. > > ZnHttpClient is a builder like interface (think of Gofer), it also has some extra features. > > ZnHTTPSocketFacade is a replacement for the current > Pharo/Squeak HTTPSocket API. In my development images, this is active, which means that all HTTP functionality (for MC for example) is handled by Zinc HTTP - a case of eating my own dog food. good! > On the server side there is ZnServer which can be customized with a delegate and authorizer. A static web file server, a Monticello server as well as a Seaside adaptor are available. > >> Do you port an existing library to smalltalk or do you figure out how it should be done right now? And what do you think about going towards cross-platform? This would need a decision if you are willing to integrate grease/sport in your client. I can imagine that this is not wanted per se because it introduces dependencies. It will be just very hard to do it cross-platform if you do not. > > The first goal of Zinc HTTP is to be useful for Pharo, to replace existing HTTP functionality in the image. Hence portability is not high on the list. Like you said, building on top of a portability layer would mean external dependencies that would most probably conflict with the first goal. But I am not against portability (most of the code except for some obvious missing crypto stuff still runs on Squeak as well). We can always try to find a solution. > > Regards, > > Sven > >

Dec. 8, 2010

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by StÃ©phane Ducasse

>> > Thanks for the explanation, some quick and dirty buffering makes a huge difference: > > [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream | > 1000 timesRepeat: [ > fileStream nextPutAll: > (String streamContents: [ :stream | > 100 timesRepeat: [ stream print: 100 atRandom; space ] ]) ] ] ] timeToRun. > 159 > > Still, the asymmetry is a bit strange. > Can't the side effects be dealt with using #flush ? > >> There are several stream libraries (for example XTreams) that can easily support write buffering without the need to care about compatibility. > > Yeah, although the Smalltalk Collection and Stream classes were better than everything else 20, 30 years ago, lots of things have changed and there is lots of competition. The fact that these classes are so nice to use seem to have prevented necessary improvements. Yes time to move. > > I think I might file this as a Pharo issue. > > Sven > >

Dec. 8, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by StÃ©phane Ducasse

> did you create an issue? >> and where did you publish the code? > > I uploaded them to the PharoInbox, but as I said, only one minor change in SmallDictionary>>remove: (adding a carrot "^" at the beginning) will fix the discrepancy between the two. But if the consensus is that Dictionary>>remove: and Dictionary>>remove:ifAbsent: should not be implemented, maybe the same should be true of SmallDictionary as well. probably. >>>>> Is anyone else bother[ed] by this inconsistency? >>>> >>>> Apparently not. Well, I uploaded two packages to the PharoInbox. One adds #remove: and #remove:ifAbsent: to Dictionary >>>> and updates SmallDictionary's implementations of those messages to return the same value >>> >>> Regardless of what comes of those packages I uploaded, SmallDictionary>>remove: and SmallDictionary>>remove:ifAbsent: returning two different values is clearly a bug. Looking at it again, I was wrong about SmallDictionary>>remove:ifAbsent: returning the key; it does return the removed association. Which means at a minimum, SmallDictionary>>remove: only needs to have a ^ inserted at its beginning to fix the discrepancy. >>> >>>> - the association removed - rather than their current behavior of #remove: returning self (no explicit return value) and >>>> #remove:ifAbsent: returning the key of the removed association. >>>> The second package adds #testRemove and >>>> #testRemoveIfAbsent to DictionaryTest (through a trait). >>>> >>>> >>>> >>> >>> >> >> >> > >

Dec. 8, 2010

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by Levente Uzonyi

On Wed, 8 Dec 2010, Philippe Marschall wrote: > On 12/08/2010 12:32 AM, Levente Uzonyi wrote: >> On Tue, 7 Dec 2010, Philippe Marschall wrote: >> >> snip >> >>> No, buffering should not be in a subclass or even the file stream class >>> itself. Buffering should be an other class that wraps file stream. >> >> Stream wrappers are cool, but they are totally different from the >> current stream design. One could create new stream classes that could do >> buffering, conversion, compression, etc. and rewrite existing code to >> use them, but if you just rewrite the existing code using an existing >> stream library (for example XTreams), then you'll get pretty much the >> same thing with less effort. > > Nope sorry, writing a stream that buffers is not less effort that > porting and maintaining a whole stream library and rewriting your code. It would be: writing and maintaining new stream classes VS using an existing port. Levente > > Cheers > Philippe > > >

Dec. 8, 2010

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by Levente Uzonyi

On Wed, 8 Dec 2010, Sven Van Caekenberghe wrote: > > On 08 Dec 2010, at 00:25, Levente Uzonyi wrote: > >>> Thanks for the explanation, some quick and dirty buffering makes a huge difference: >>> >>> [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream | >>> 1000 timesRepeat: [ >>> fileStream nextPutAll: >>> (String streamContents: [ :stream | >>> 100 timesRepeat: [ stream print: 100 atRandom; space ] ]) ] ] ] timeToRun. >>> 159 >>> >>> Still, the asymmetry is a bit strange. >>> Can't the side effects be dealt with using #flush ? >> >> Lets go back in time. A year ago there was no read buffering (Pharo 1.0 was not released, Squeak 3.10.2 was out) and reading from a file was as slow as writing is currently. Read buffering could be added transparently, so it could give a huge speed improvement to all existing code. >> Write buffering could be done the same way, but it would break code, because currently a write is immediately done, while with buffering it >> wouldn't be. Some files would be written only when the finalization process closes the file. The solution for this could be automatic flushing on each write, which could be turned off by a method. But that would be the same as not using write buffering at all. >> But with the same effort you could use another stream implementation, that does write buffering. And write buffering can't be used to speed up existing code without reviewing it. > > Thanks again for the explanation. > > OK, I tried writing my own buffered write stream class: > > [ FileStream fileNamed: '/tmp/numbers.txt' do: [ :fileStream | | bufferedStream | > bufferedStream := ZnBufferedWriteStream on: fileStream. > 100000 timesRepeat: [ bufferedStream print: 100 atRandom; space ]. > bufferedStream flush ] ] timeToRun. > 165 > > That wasn' too hard. And indeed, it is necessary to manually send #flush or #close to force the buffer out. > > But I do not completely agree with the fact that it would be that much work. Stream>>#flush is already a no-op. Adding it to #streamContents: and some others can not be that much work. In fact, SocketStream does already do both input and output buffering (and thus requires #flush or #close), so would potentially fail in certain situations according to your reasoning. No ? It would be much work to add the write buffering to StandardFileStream (it should also work with MultiByteFileStream) and fix all places in the image, that use StandardFileStream or MultiByteFileStream for writing to a file. I don't get how #streamContents: could be used to send #flush. That's a method of SequenceableCollection IIRC. SocketStream is unrelated here, because it doesn't write to files and buffering was always implemented in it AFAIK. Levente > > Sven > > >

Dec. 8, 2010

Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)

by Marcus Denker

On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote: > > On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote: > >> Ok, I've done some fixes to OB and OC, and committed them to PharoTaskForces as a temporary solution. >> >> To load current configuration: >> >> Gofer it squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfPharo'; >> load. >> >> (ConfigurationOfPharo project version: '1.2-beta2') load. >> >> Can Hudson help us in building Dev images? > > > Yes, will set up a build for 1.2 today. I have set one up that takes 1.2 core, runs updates and then tries to build dev https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ It is failing right now. https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 8, 2010

[Pharo-project] socket deadlock using Cog VM

by Johan Brichau

Hi, We are experiencing a deadlock in Socket>>waitForDataIfClosed: The problem occurs on Pharo11/Pharo12/Squeak41 only when using the Cog VM. In our particular case, the socket connects to a GOODS database and it started occurring with a growing amount of data (so longer connections, more data transfer). When you open a debugger on the deadlocked process and proceed the process, it will simply continue and finish without problems. We are using Cog VM of 4 october, downloaded from Eliot's website (VM.r2316/) Before I start isolating the problem and reproduce it without requiring GOODS (it's just an http socket anyway): Is anyone else experiencing similar issues here? Is there a fix in more recent versions? cheers Johan

Dec. 8, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by Sven Van Caekenberghe

On 08 Dec 2010, at 10:48, Lukas Renggli wrote: > Very cool framework, I like it a lot! I definitely vote to eventually > replace HTTPSocket with Zinc HTTP Components. Thanks a lot, I am glad you like it. > I wonder why ZnFixedClient is not a subclass of ZnHttpClient? Well, ZnFixedClient is what I wrote earlier for my needs (I use it inside a T3RestJsonClient, then T3CachingRestJsonClient and finally a business specific T3Client, works very well). ZnHttpClient is Matt's later version, partially inspired by your idea of a builder-style API. > I think it would be cool to be able to use them polymorphic. We could maybe use some refactoring, consolidation, redesign (hint, hint). But for me, it is also a search for good solutions where I don't think that one size will fit all, but I could be wrong (for example, Matt's redirection, cookie and more advanced authoritzation support would be nice to have everywhere, it is just that I did not need it yet in my applications). Sven

Dec. 8, 2010

Re: [Pharo-project] Why is FileStream writing almost an order of a magnitude slower than reading ?

by Philippe Marschall

On 12/08/2010 12:32 AM, Levente Uzonyi wrote: > On Tue, 7 Dec 2010, Philippe Marschall wrote: > > snip > >> No, buffering should not be in a subclass or even the file stream class >> itself. Buffering should be an other class that wraps file stream. > > Stream wrappers are cool, but they are totally different from the > current stream design. One could create new stream classes that could do > buffering, conversion, compression, etc. and rewrite existing code to > use them, but if you just rewrite the existing code using an existing > stream library (for example XTreams), then you'll get pretty much the > same thing with less effort. Nope sorry, writing a stream that buffers is not less effort that porting and maintaining a whole stream library and rewriting your code. Cheers Philippe

Dec. 8, 2010