Re: [Pharo-project] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)

I saw this thread on the pharo list and figured that a bit of feedback from Michael and myself might be helpful. Please, forgive the cross-posting, this concerns both dialects and I'd like to make this discussion visible on the VW side as well. First of all, let me thank everyone for the "xtrea

Re: [Pharo-project] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)

"Nicolas Cellier" wrote: > More example than the site http://code.google.com/p/xtreams/ ? If so, I'm > interested. Not more, but different. For example I'm quite fond of the Morse code decoding example: ('. ... ..- --. -... .- .-. -.-. . .-.. --- -. .- -- -- -..- ' reading

Re: [Pharo-project] Xtreams port to Squeak - second wave

Hi Nicolas, "Nicolas Cellier" wrote: > Hi again, > I now have ported two more packages > - Xtreams-Transforms > - Xtreams-Substreams > and their tests This is great! I loaded your code into Pharo 1.1 and things seem to be working quite well. There was a complaint about missing SharedQueue2, I ju

Re: [Pharo-project] Xtreams : first embryonary port on Squeak

"Schwab,Wilhelm K" wrote: > FWIW, SIF might help you: > >http://www.pocketsmalltalk.com/sif/ > > I have put a lot of code through it in the past couple of years. I'd recommend giving the Monticello tools in VW a try before trying to put something together from lower level tools. It's used t

Re: [Pharo-project] Xtreams port to Squeak - second wave

"Nicolas Cellier" wrote: > Then, the harder work begins: > - File/Socket/Pipe > - Pointers (in External Heap) > - Character encoding/decoding I just published XtreamsDevelopment(387) with following changes: * abstracted Encoder out of encoded streams to allow implementing our own encodings. * En

Re: [Pharo-project] Xtreams port to Squeak - second wave

"Sven Van Caekenberghe" wrote: > I tried to follow your different releases in Pharo 1.1.1, right now I have > 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and > #..multipleBufferSize). If will send you the report. > > I have been trying some of the examples from the do

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

"Levente Uzonyi" wrote: > Okay, I really tracked down the cause of the problem. The tests perform > simple producer-consumer scenarios, but the consumers won't wait at all. > If there's nothing to consume, the test fails. The randomness come from > the scheduler. The server process is started fi

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

"Sven Van Caekenberghe" wrote: > >> I also found an issue: the process in XTTransformWriteStream doesn't > >> terminate. If you run the tests, you'll get 12 lingering processes. > > > > I don't see that happening in Pharo 1.1. Normally the process should end > > normally when the stream is close

[Pharo-project] Xtreams vs become:

Michael and I talked about this today a bit and here's what we're thinking about doing. We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one

Re: [Pharo-project] Xtreams vs become:

"Nicolas Cellier" wrote: > I've tested this strategy, and it works well: > > - use accessors self input/self output instead of inst. var. > - lazily initialize the input for Collection and File Sounds good to me, less work too. I just thought the write:read: approach makes it clearer that you ne

Re: [Pharo-project] Transforming WSDL in a local model - Which HTTP client ? (was Web Services - SoapOpera problems)

"Philippe Marschall" wrote: > Yes, SOAP it not just some XML format. You have to sink a lot of > resources into the implementation and tool support. Keep in mind that > even Cincom with all their resources didn't manage to make their SOAP > library talk to SAP. They had to build a proprietary conne

[Pharo-project] Xtreams updates: positioning, slicing and stitching

I updated the Xtreams port (http://www.squeaksource.com/Xtreams) over the holidays to catch up with the state on VW side. The primary changes are updates/fixes of the positioning API and a cleanup/extension of the slicing API. The slicers are replaced by much simpler #slicing setup and the inver

Re: [Pharo-project] Xtreams updates: positioning, slicing and stitching

"Francisco Ortiz Peñaloza" wrote: > Hi Martin, thanks i'll try it later! > > It would help if you could provide a Metacello configuration for it. Yes, something like that is clearly needed, but I'm still finding my way around the environment. However at the moment Xtreams don't have any prerequis

Re: [Pharo-project] new Cog VMs

I'm probably doing something obviously wrong, but I have no luck with the Cog VM. It crashes immediately on startup even with the stock OneClick image. I downloaded the Pharo-1.1.1 OneClick images. Fetched the latest coglinux.tgz (r2340), untarred it into the pharo directory and just trying to r

Re: [Pharo-project] new Cog VMs

"Eliot Miranda" wrote: > so find new VMs in > VM.r2341/. Yup, much better on my end. Thanks! Martin

Re: [Pharo-project] about growing streams and allocating buffers

"Philippe Marschall" wrote: > > preallocation OrderedCollection new: instead of relying on its growing > > behavior. > > Right, but you never know how big the response is going to before > actually rendering. Otherwise you could just do Array/String new: > beforehand. I'm not quite clear abou

[Pharo-project] Xtreams up to date

Hope it's OK to cross-post this, I figured there might be interested people on both sides. I finished the updates of the Xtreams port to match the VW version, so everything (that is available) should work as advertised in the documentation (http://code.google.com/p/xtreams/). Besides the implem

Re: [Pharo-project] Xtreams up to date

"Torsten Bergmann" wrote: > Used your Gofer script in Pharo-core 1.2 and Pharo-dev 1.1., > but after loading I run the tests with many errors and failures... Hm, that is odd. Maybe I need to try a fresh load and see. I normally get a single failure in one of the socket tests which we haven't trac

Re: [Pharo-project] Xtreams up to date

mkobe...@gmail.com wrote: > Hm, that is odd. Maybe I need to try a fresh load and see. I normally get a > single failure in one of the socket tests which we haven't tracked down yet. > Can you give me a bit more about the kind of errors and failures you see. > Does it look like stuff is complete

Re: [Pharo-project] Xtreams up to date

"Henrik Sperre Johansen" wrote: > Can't just load the CoreTests and have all tests pass though, due to > the isAbstract implementation in XTReadingWritingTest. > Maybe XTReadingWritingTest, XTInfiniteReadingWritingTests and > XTFiniteReadingWritingTests should be moved to the Terminals-Tests pack

Re: [Pharo-project] Xtreams up to date

mkobe...@gmail.com wrote: > mkobe...@gmail.com wrote: > > Hm, that is odd. Maybe I need to try a fresh load and see. I normally get a > > single failure in one of the socket tests which we haven't tracked down > > yet. Can you give me a bit more about the kind of errors and failures you > > see.

[Pharo-project] Socket question (Was Re: Xtreams up to date)

I started looking at the Socket failures that I can reproduce and I can't wrap my head around the SocketReadingWritingTest>>setUp. Based on what I know about TCP sockets it doesn't make sense to me. AFAIK to get both ends of a connected TCP connection (lacking a socketpair call) I need 3 sockets

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

Thanks everyone for your responses. I studied the ConnectionQueue that Wilhelm pointed me to, that didn't clarify things for me too much and I wasn't able to get it working either. Finally Sven's version of the script got me going again. I can already see the first problem in the Xtreams impleme

Re: [Pharo-project] [squeak-dev] Xtreams up to date

"Sven Van Caekenberghe" wrote: > Thank you for all this work, this is a really interesting project, I am glad > you are putting in the effort to bring this to Pharo/Squeak. Thanks. It's Nicolas who deserves the praise. I'm just trying to help out. > ... > I tried to look at one of the others >

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

"Levente Uzonyi" wrote: > It works fine in my Squeak image. Using localhost may be a problem if your > local interface has an IPv6 address. Use 127.0.0.1 instead. Odd. The image I was using must have been corrupt somehow. When I took fresh Pharo 1.2 image the script worked fine. Thanks for the co

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

OK, with two minor tweaks the socket streams started to behave better for me. The whole suite passes sometimes, although the results get often spoiled by transient failures which suggest a race condition in transform write stream. I think it's the the same one I occasionally see on VW side altho

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

BTW, would this snippet be useful as a basic Socket smoke test ? Or is that already covered somewhere ? | input output listener process sync | sync := Semaphore new. listener := Socket newTCP. listener listenOn: backlogSize: 10. process := [ [ input := listener waitForAcceptFor

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

"Sven Van Caekenberghe" wrote: > Each #acceptWaitTimeout seconds, 'Wait for accept timed out' is printed on > the log and another accept/wait starts. This looping improves liveliness and > responsiveness to other events. Given that accept is generally done on the server side, usually in a backgr

[Pharo-project] Xtreams-Xtras: hashing and HMAC

I started playing with FFI and got the hashing streams working. They require OpenSSL's libcrypto, which should be available on any reasonably recent Unix and OSX. The VW version also has interface to native Windows bcrypt.dll (available on Vista and later) but I haven't done that part yet. Anywa

Re: [Pharo-project] [squeak-dev] Re: Xtreams-Xtras: hashing and HMAC

"Sven Van Caekenberghe" wrote: > > The code is in Xtreams-Xtras and Xtreams-XtrasTests (note that you'll have > > to load FFI!). I tested it on Pharo 1.2 beta with both cog vm and standard > > vm. There are few test failures with file terminals that don't seem to like > > to be closed twice. Sho

Re: [Pharo-project] Xtreams-Xtras: hashing and HMAC

"Sven Van Caekenberghe" wrote: > > I didn't find a way to browse a "package" in Pharo 1.2 so I'm struggling a > > bit to keep the categories in line. > > Hmm, click the 'Browse' button in either the Monticello Browser or the > Repository Browser with the correct package selected ? But I guess you

Re: [Pharo-project] [squeak-dev] Xtreams up to date

"Hannes Hirzel" wrote: > If I explore the resulting object I got what is shown in the screen > shot. I am not sure how to interpret the result. Yes, it's not the best possible representation, but it does show the full parse tree. The tree can be rather complicated depending on how complicated is

Re: [Pharo-project] [squeak-dev] Xtreams up to date

"Hannes Hirzel" wrote: > I worked through it and understood it. I adapted the class names so > that it runs in the current Squeak 4.2 out of the box. In addition I > edited it slightly. I think it could be added as to the PEGParser > class. Maybe somebody else like to check it in addition Yes

Re: [Pharo-project] Gofer issue

What about branch from a branch ? In general you need a tuple of (base version, branch id, branch version) to identify a branch version. Similarly a branch on a branch would become ((base version, branch id, branch version), branch2 id, branch2 version). In VW we use the following convention

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

Most probably know this, but just in case, recent versions of Linux distributions provide a more modular way to control the library path via the /etc/ld.so.conf.d/ directory. For example I normally add path to oracle libraries by adding a file /etc/ld.so.conf.d/oracle-11.1-x86_64.conf with just

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

"Janko Mivšek" wrote: > Ralph Johnson in his InfoQ interview made an interesting observation: > > 2:55 minute: "Smalltalk made an fundamental error ... image ... you can > build something with 4-5 people what 50 people can build in Java, but if > you take 200 people in Java ... it is really designe

[Pharo-project] Cincom Smalltalk Team is hiring!

We're looking for experienced developers with passion for Smalltalk. We're especially interested in candidates that have experience relevant to VM development, or GUI/Tools development. Following link provides information on how to find the descriptions of the openings and how to apply: http://

Re: [Pharo-project] Help "migrating" from classic streams to XStreams

"Mariano Martinez Peck" wrote: > Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary > serializer similar to Parcels. More info in > http://rmod.lille.inria.fr/web/pier/software/Fuel > > For the moment, we are using the "classic" streams we want to give it a try > to XStreams. My kno

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

"Miguel Cobá" wrote: > But the performance is an issue. And I think that there was a discussion > several years ago that lead to choice a plugin instead of the > all-smalltalk code (independently of the queality of the smalltalk > code). Also a point was made about the maintainability of the smallt

Re: [Pharo-project] How to encrypt a password?

"Milan Mimica" wrote: > To make it slightly more secure, you can put a little salt in it: > > salt := 'Some random string I just cam up with 123' > > password:= SecureHashAlgorithm new hashMessage: salt, aClearTextPass. > > check: > password = SecureHashAlgorithm new hashMessage: salt, aPasswordAtt

Re: [Pharo-project] How to encrypt a password?

"Milan Mimica" wrote: > Yes, having the salt randomly generated and storing it with a hash is a > better idea. Note taken. Combining it with a fixed salt (and trying to keep > it secret) is even better. Keeping a hardcoded salt in the image running on > the remote machine serving WEB pages makes it

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily just experimenting with Cypress. However the master branch there is misleading, it contains a very early port of Xtreams to ST/X (there's a much more up to date version in Jan's ST/X project @ https://sw

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

"Colin Putney" wrote: > > While I'm on the topic, I'm considering some API changes and am not sure > > how to go about discussing it. I don't want to cross post discussions to a > > number of mailing lists, so I think I'm inclined to just cross-post an > > invitation to anyone interested to subscri