Squeak-dev August 2007

squeak-dev@lists.squeakfoundation.org

132 participants
163 discussions

Re: [ANN] Smagick
by Kevin Driedger 17 Aug '07

17 Aug '07

I've tried it on Windows and stepped through the code a bit and it seems that you are assuming that the names of the binaries will be without extensions but on Windows they add .exe to the end. I'll see if I can change that. ]{evin stefan.reichhart(a)gmx.ch wrote: Hi, Thanks (to all) for the nice feedbacks ! request by Damien: "Smagick 0.1" is now available as Package Universe ;) interfacing: Right now the "IO" between "Smagick" and "Image Magic" via "OSProcess" is done using "OSProcessIO". That is an intermediate layer that composes the commands for a model (=Smagick) and returns the parsed output (if there is any) and the process of an external application (=Image Magick) back to it. "OSProcessIO" is using a file- pipe for this ... yet very primitive. I know that "Smagick" works well on Unix, Linux and MacOSX - tested and heavily used. I don't know whether it runs on Windows. Maybe someone can try it ? - I don't use Windows anymore ... Cheers, Stef On Aug 7, 2007, at 3:54 PM, Lex Spoon wrote: >> "Smagick" is a small high level interface to control "Image Magick" >> from within a Smalltalk environment, eg. Squeak. The purpose of this >> package is to provide high performance image manipulations without >> the need to know all the low level details of image processing. > > Neat!! > > There is a ton of stuff available on our machines outside of Squeak. > There are several ways to access such things, and Smagick's approach > is to use OSProcess. > > Can you comment on how the interfacing works? Does Image Magick have > a mode that lets you talk to it over a pipe, or does it have a rich > set of command-line options that Smagick can use, or what? > > Also, does anyone have an idea if Smagick works in Windows, possibly > with Cygwin? How about OS/X ? > > > Lex > -- ]{evin ])riedger 1473 Brule Ave., Ottawa, ON http://extremedesigners.ca

1 0

[ANN] Smagick
by leves＠elte.hu 17 Aug '07

17 Aug '07

Since OSProcess doesn't work on windows Smagick won't work without changes. I've got a version (based on Smagick-SR.27) which uses ProcessWrapper instead of OSProcess and it works under win32, but i had issues with Image Magick under windows (ImageMagick-6.3.5-Q8 and ImageMagick-6.3.5-Q16). If anyone is interested, let me know, and i'll make the code available. Levente

1 0

Problem loading FFI
by Andreas Wacknitz 16 Aug '07

16 Aug '07

If have problems loading FFI-3.9.1 into a fresh 3.10-7142 image. I'll get an "Error: can't find EOCD position". See the appended SqueakDebug.log file. Is this a temporary problem? Regards Andreas

3 3

the future is Supertool...
by Keith Hodges 16 Aug '07

16 Aug '07

Some thoughts > The future , as Goran said on Supertool, is not Monticello. > Monticello is good for some, but is not the silver bullet. > > I dont agree with this SuperTool is the future approach, having lived with MC2 is the future for all too long. It has taken years for the use cases to form around the current tools and some of these are non trivial. I expect any new tool will do the easy stuff and fail to do the difficult stuff and we will be back where we started. It takes a lot of effort and "going around the loop" to dot all the i's and cross all the t's. So I think we would be better off actually finishing one tool (MC) or even its successor (MC2) before starting on another. For example the case where you want to maintain several versions of the one method in the image: You want the original method to stay with its original package so that when you save the original package that package does not get broken. You want your changes to stay with your package so that that does not get broken. This is not as easy as it sounds. A second example, however you do it, the out-of-order loading supported by MC1.5 requires a cache of not-yet-loadable elements, I call this the orphanage. Orphans get rehomed once the parents arrive! So whatever tool you come up with will have the same basic elements, like MC1 has MCMethodDefinition MCClassDefinition MCClassVariableDefinition etc and a loader to apply them, browsers to look at them, differs to compare them etc. Why have 1 technology when you can have 4. (MC MC2 SuperTool and SystemEditor) I mention SystemEditor because I think that a persisted system editor would make a useful binary package distribution format which only needs SystemEditor to atomically load! MC supports Diffs in theory, so the "packages are too big" argument can be tackled. I started to add changset support to MC1.5 as well. This makes sense because MC already has browsers for all this stuff. By all means improve the recent changes and change sets support, this will help all tools to work better. But is the changeset functionality not wired in a deep way in all of the forks that this is aiming to support? Migrating everyone to this new scheme is not going to be easy. Personally I think that MC1.5 with SystemEditor working (MC1.5 is ready its SystemEditor that is not trested) would be a winning combination. I also think that MC can be simplified and slimmed down a lot with SystemEditor support working. I am disappointed that we are unable to raise the effort to get SystemEditor tested and usable. This is a bottleneck for all the initiatives which want to use it MC1.5 MC2. and Supertool, so I think it should be THE priority task. (I am a bit snowed under for now myself) sorry for being overly cynical Keith > I wish some could help me for not having Monticello in the base image. > Only we need a "Monticello loader" and people could load Ralph version, Avi > version, Impara version, Keith version . > > Or none of this in a year from today when Supertool is builded and adopted. > > Edgar > > > > _______________________________________________ > V3dot10 mailing list > V3dot10(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/v3dot10 > >

3 3

[ANN] ViewPoints, was: Re: An idea, crazy or not?
by Igor Stasenko 15 Aug '07

15 Aug '07

On 14/08/07, Darius Clarke <socinian(a)gmail.com> wrote: > > I'm already start thinking about implementing some simple protocol for > > interacting with public server. A message protocol can be very dumb > > and straightforward, like: > > > > - list class log entries (class, start date , end date). > > - list package log entries (package, start date , end date). > > - fetch entry by id. > > - add class log entry (date, author, type, contents) > > - add package log entry(date, author, type, contents) > > > > a basic entry types can be: > > - create topic > > - add comment to specific topic > > - add new delta (also creates topic) > > - vote for entry (accept/reject) (you can vote , giving your approval > > for some delta, or for someone's point of view). > > > > A voting is good to collect information about what people think of > > given update. Then admin/GOD/package maintainer can simply click > > 'Approve' or 'Reject' a change. And all users will have a single > > button 'Download approved changes'. > > Nice! Let me know when I can test it! > Here is pre--pre-pre...alpha snapshot: http://www.squeaksource.com/ViewPoints.html. I didn't even run it once (too tired now) Take a look and say what you like and what not, what to add , what to remove. And/or add/remove yourself , i made repository open for write. Any comments welcome from anyone. This tool will serve for making comments and exchange them, so please start doing this now :) -- Best regards, Igor Stasenko AKA sig.

1 0

Mock-Framework for Squeak?
by Robert Krahn 15 Aug '07

15 Aug '07

Dear Squeakers, I was looking for a Mock-Framework for Smalltalk but noticed that there is only SmallMock (http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=S…) which seems to be outdated and not available any more. Have I missed something or are there really no mocks for Squeak? I thought of something like SMock (http://www.macta.f2s.com/Thoughts/smock.html). Thank you, Robert

3 2

about IPv6
by Philippe Marschall 15 Aug '07

15 Aug '07

Hi Browsing in the vm SVN repository I found some hints to IPv6 support (at least on UNIX). What's the status of this? IIRC the OLPC guys once said they'd probably gonna need it? Is an IPv6 address modeled as a ByteArray of size 16? Cheers Philippe

5 5

Re: Re: [Q, OT] Book for Smalltalk, like SICP for Scheme/Lisp
by "S.J.Chun" 15 Aug '07

15 Aug '07

I already read the book you mentioned. But I do want more profound one, which should cover the areas which is civered in SICP; from basic programming elements to the machine/system(virtual one) construction, which is the reason I think SICP is the one of the best book for educating programmer(like TAOCP). Thank you. ----- Original Message ----- From: Michael Haupt <mhaupt(a)gmail.com> To: "\"S.J.Chun\"" <chunsj(a)embian.com>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Sent: 07-08-15 18:24:45 Subject: Re: Re: [Q, OT] Book for Smalltalk, like SICP for Scheme/Lisp Hi, On 8/15/07, "S.J.Chun" <chunsj(a)embian.com> wrote: > During my reading of SICP :-), I thought that it would be > great if there is some equivalent book for Smalltalk. So, I > post my question here. there is a book by Gene Korienek et al., entitled "Squeak: A Quick Trip to Object Land" (ISBN 0201731142). It is written in dialogue style (a bit like the "The Little Schemer" book by Friedman/Felleisen) and actually is an introduction to OOP, where Squeak is used as the language/environment of choice. Given that the book was published in 2002, the version of Squeak used therein is not very recent (3.0, I think). There are others, of course, but this one seems to be close to SICP when it comes to comparing the approaches. It does not go as far as SICP, though, in terms of the complexity of the examples. Best, Michael

2 1

DeltaStreams!
by Göran Krampe 15 Aug '07

15 Aug '07

Hi all! I am glad for the responses so far to this idea. Some answers: Jason: Darcs? Nope. :) I love Darcs and have used it quite a bit. I also love Mercurial. Lately I have come to the "conclusion" that magic like Darcs is cool but can also be a pure PITA when stuff suddenly doesn't work. With Deltas I want stuff to be very simple and you should not get surprises or wonder why it did what it did etc. So the "smartness" here will be based on other techniques than complicated historical analysis etc. Keith: SystemEditor? Yes, definitely! Loaded the latest and intend to use it! Brad: Started coding last night, not before my original post. :) See below. Ron: Yes, I think we need "standard packages" but I also think such a package can have at least one official stream, possibly a few, and most probably a few "non official" fix streams associated with it. So I don't see the concept of Packages being replaced here - rather complemented. And sure, if we end up with a collage of streams it might not make us any wiser, but with a bit of careful design in how this will work I am hoping the confusion can be minimized - as Andreas noted - we need to reference MC snapshots etc somehow to tie it all together. Ideas welcome! Igor: I don't agree in full regarding globals. IMHO it is not a solution to "get rid of them". The globals are our common namespace. It is the basis for our communication and interoperation. When I say Socket - you know what I mean. And as you also pointed out earlier - analyzing globals is an efficient basis for figuring out dependencies automatically. So I want to keep them - possibly amended with my "prefixes improved" approach - but I am not pushing that! DeltaStreams etc is meant to work in all major Squeak forks and I don't see them all dumping globals any time soon. :) Colin: Nice to hear your views - I value them a LOT given your domain knowledge here (MC/MC2). One thing I have come to appreciate after experience with tools like MC and Darcs and now lately Mercurial (and earlier ChangeSets) is that simplicity (Mercurial/ChangeSets) can sometimes beat smarts (MC/Darcs) in *practice*. MC rocks in certain scenarios (a few devs working on a common package) but does nothing for others (small fixes, moving fixes in one fork into another). My wish is for a toolset which leverages simplicity. It does not need to be *magically* smart, just a bit smarter than ChangeSets - if it handles 90% of the cases REALLY GOOD and fails in an EXPECTED way in the other 10% and then easily let developers "hack it" - I will be very satisfied. I will try to sketch down use cases so that we can explore together how these Deltas could/should behave - and thus learn more - trying to keep an open mind to how merging/conflicts/dependencies can be approached. And oh, I am using SystemEditor of course. :) Andreas: Great to hear that you think it sounds useful! I agree, let's make it dead simple so that we can get it operational soon. Working with MC - I agree, also not sure what it will entail. :) The problem of "which deltas do I have" and "which do you have" is indeed the "history problem" and normally the basis for more advanced merging. I want to explore some use cases before making Deltas smarter than what I described. I am hoping that the combination of: 1. Making a Delta know *both* after and before state (like both the old method source and the new for a simple method change). 2. Making it more granular and defined, like actually having a AddedInstVarAction (and several more of course) instead of "class definition was changed somehow". ... will enable enough smarts without having to go into too advanced historical analysis. Also - if the streams (both your own and the one it originates from) are available we have lots of history. Again, great to hear you like the basic idea! I want to get this rolling in a loose team, I can't pull this one all myself - we need to do it together. It will be seriously KISS, the simplest working solution - and then evolve. So if you would like to help out, email me, and I will add you as developer: http://www.squeaksource.com/DeltaStreams (just created) Class prefix for code: DS PI: DeltaStreams I also created a Swiki page for it, will stuff all info in there. I have started writing class Delta and DeltaTest based on careful reading of ChangeSet and reimplementing it fully, but *better* of course. :) I will use latest SystemEditor. I will make first small snapshot later tonight, first code sits at home in an image. regards, Göran PS. Apart from exploring using code I want us to discuss and write down use cases. Please help with that!

3 2

[Q, OT] Book for Smalltalk, like SICP for Scheme/Lisp
by "S.J.Chun" 15 Aug '07

15 Aug '07

Hi, During my reading of SICP :-), I thought that it would be great if there is some equivalent book for Smalltalk. So, I post my question here. Any suggestion or recommendation?, any book/doc. are ok. Thanks in advance.

3 2

← Newer
1
...
8
9
10
11
12
13
14
...
17
Older →

Jump to page: