Squeak-dev January 2006

squeak-dev@lists.squeakfoundation.org

164 participants
300 discussions

[Morphic] I wish know when was the last image in what Nebraska performs as designed
by Lic. Edgar J. De Cleene 31 Jan '06

31 Jan '06

I send direct to this list because I don't have response to mails what I send to morphic - list I continue trying to figure the elusive unloading of Nebraska. In several different images I have problems. In particular, in NebraskaServer comment you read. To start a server, execute the following code: NebraskaServerMorph serveWorld: World To start a client, run the following in another image: NetworkTerminalMorph openAndConnectTo: 'servername' This don't work in 3.6, 3.7, 3.8 or 3.9, so I wish advice Very thanks. Edgar ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar

8 19

Re: planet urls ?
by Simon Michael 31 Jan '06

31 Jan '06

PS, if other non-english-speaking communities want a planet, send me the blog urls.

1 0

planet urls ?
by Simon Michael 31 Jan '06

31 Jan '06

Good morning all. Nice to see a few of you at C5. Ken Causey and I set up redirecting/proxying so that http://planetsqueak.joyful.com can be reached at http://planet.squeak.org . I'd like to do the same think for the other three planets, and use *.squeak.org as the canonical urls. They are: http://planetsqueakes.joyful.com/ http://planetsqueakarchive.joyful.com/ http://planetsqueak2.joyful.com/ What should their new urls be ? I propose simply planetes.squeak.org planetarchive.squeak.org planet2.squeak.org for the moment. Better ideas ? Thanks -Simon

1 0

SqueakSource migration next Monday
by Adrian Lienhard 31 Jan '06

31 Jan '06

We plan to move SqueakSource (www.squeaksource.com) to a new server and at the same time upgrade the version. Hence, the service will not be available for a couple of hours next Monday afternoon (GMT+1). Requests to the old server (kilana.unibe.ch:8888 which is probably still in use instead of squeaksource.com) will be forwarded so that no changes should be required. Adrian ___________________ Adrian Lienhard www.adrian-lienhard.ch

4 6

RE: Squeak, source control, subversion, versioning, monticello, all that good stuff.
by Peter Crowther 31 Jan '06

31 Jan '06

> From: [...] Simon Kirk > The only other need for a strict branching discipline is maverick > developers who have a habit of refactoring large swathes of shared > library code in the main codebase that impact other people, live > deployments, testing, etc. How would you suggest stopping people from > being able to do this sort of thing? First offence: Being beaten over the head ritually with the procedures manual, in which it is said that You Don't Do That. Second offence: Being transferred to an XP team, where such behaviour is tolerated. Third offence (if they manage to alienate the XP people): Dynamite. Or being assigned Wally (from Dilbert) as a pair programmer. More seriously... there's not really a technical way of preventing this. Human approaches are required, which can (should?) include removing the maverick from the project, and possibly the company. Seems harsh, but I've seen such a person wreck a project. - Peter

2 1

Squeak, source control, subversion, versioning, monticello, all that good stuff.
by Simon Kirk 31 Jan '06

31 Jan '06

Hi Squeakers. Bit of an internal monologue here about something that's been concerning me about Squeak development for a while now: Source control. Please excuse the verbosity. Specifically, over time at my last two companies I've worked with others on developing a development process using CVS (later Subversion) that allowed development to happen on a fair-sized codebase, across a team of up to about 30 or 40 developers. Nothing particularly special, it uses the idea of "branching a lot" as opposed to "branching a little", but it allows the tight integration of a bug tracking tool with ones source control, and potentially (although the reality is often less idealistic, obviously) keeps fixes for bugs nicely segregated from the rest of the code until they're merged. Note that this has always been on file-based languages (Java in this case). But with a major smalltalk-related caveat, which I'll get on to shortly. It's how I'd like to be able to work now with Squeak, but obviously things are different in image-based-development-land. Just to elaborate a little on the process: There's a "main branch" of development, commonly referred to (in my experience: Note that my terminology may differ a lot to what people are used to, so please bear with me :) as the HEAD with cvs/svn. The state of this branch is arbitrary, really - although generally for me it was always the latest main development/unstable/latest&greatest version of the product the source-controlled codebase represented. We then also used the branch-per-product method: In an ideal world a new version of the product would be released to the world against a known cvs/svn tag. Further maintenence against that version would then be performed in a branch made from that tag, and would henceforth live seperately from the HEAD. This process could continue as futher maintenence releases were made from *that* branch, etc etc. One could end up with version numbers like, 1.1, 1.2, 1.2.1, 1.2.2, 1.2.2.1, say. You get the picture I'm sure (I hope!). We went a bit further (people may disagree here), and pushed branching to the extreme: We branched for each and every defect change, naming that branch against the bug number from our bug control software. Yes, it took a lot of training to get the developers used to and happy with this process, but once we did it became much, much easier to track changes related to certain bugs, merge those changes into other branches (ie back/forward porting bugs fixes between versions), review the changes for a bug atomically, etc. We were pretty happy with it. Of course one might point out that this model pretty much negated one of the nicest parts of cvs/svn: that it allows developers to concurrently work on the same files at once, and on face value you'd be right. However, often we were working in a "large bug branch" that was really a large branch related to a large new development, with at least two developers (both assigned to the same bug) working on the same branch at once, so here the concurrent modification came into play. Now for the caveat: The model was based upon the original development environment that my previous company were using before we switched to Eclipse, VAJ (Visual Age forJava), in other words loosely based upon development using ENVY - therefore loosely based on a reaonable Smalltalk development practice. Now I find myself at the point of trying to justify Squeak for development here at my current job. I've got a lot of backing from "upstairs", but I want to know that if we use Squeak we can have the same level of granular control over source modification and control that I've had with Java in the past. To my current understanding Monticello just doesn't cut it - in fact (harsh as it may sound), the merging/diff tools in Squeak generally seem inferior to svn or even VAJ/ENVY. I seem to recall a post to this list that I read once from Avi saying that Monticello was more of a version delivery system than a source version control system - in other words that it was more useful as a way to deliver the upgrade of a version of a complete package at once, rather than people "checking code in an out" all the time as is more the case with cvs/svn. Is this right? Similarly, there was a system that Avi wrote a while back (I think this was pre-MC) called DVS. However the archive on squeak dev isn't clear on exactly what it was. From what I read it seemed much more a "snapshot all of the image and shove it straight into whatever scm we're pointing at" system, rather than dealing with individual files. I may however be doing it an enormous injustice here. Another thing that was recently mentioned was some work around MC2, but I don't know if that will support the multi-developer process I described above either, because of the general problem I've had so far: Try as I might I cannot find enough information on how to manage a smalltalk development within a multi-developer environment. Sure, I can see how MC works on a high level. But for sharing code it seems like it just won't work in the way I envisage it. Therefore I find myself thinking that either I don't understand MC/MC2/Envy and even Squeak development properly yet (highly likely as I've only been using Squeak since last July, and even then not exclusively by any means), or that the current systems out there don't support what I want at all, or that the development process I've described above is flawed. So having gone through all that preamble (and that hopefully whatever poor souls have made it this far now have a handle on the way I used to work) I can ask the simpler question: Using Squeak how would one go about developing a system in a safe, recordable and easy manner in a multi-developer environment, while maintaining linkage with a bug-tracking system such as bugzilla, in a way that is non-obtrusive* to the developer? Cheers for reading, I hope it makes sense. Simon * Here I'm talking about the auditing of changes against bug fixes: For instance with subversion I have a number of tools available: Fisheye from cenqua allows me to track who's checking what in where via RSS, and scmbug glues svn and bugzilla together such that comments of the form "bug 45: Some changes for this bug" will automatically put a comment into bugzilla against that bug: Getting developers to responsibily and happily use bug tracking software is quite a challenge! This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

13 27

does visualworks work on new macintel?
by stéphane ducasse 31 Jan '06

31 Jan '06

Hi all I would like to know if Squeak works on the new machines from apple based on intel. Stef

3 3

Error while setting jpeg background from file (primitive failed)
by Petr 31 Jan '06

31 Jan '06

Hello Squakers! I tried to set background image in the latest image (6718). However, I am getting an error calling a primitive. primJPEGReadImage: aJPEGDecompressStruct fromByteArray: source onForm: form doDithering: ditherFlag errorMgr: aJPEGErrorMgr2Struct <primitive: 'primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgr' module: 'JPEGReadWriter2Plugin'> self primitiveFailed I tracked down, that this error was introduced in (6706). Before this version the problem doesn't appear. I tried this under windows only. Petr

11 16

wxsqueak no morphic ?
by serge vi 31 Jan '06

31 Jan '06

Maybe it has been asked before, but i was wondering if it was possible to imagine a squeak starting directly with wx widgets and without morphic ( to be smaller). It's not i don't like morphic of course, but i'm working on long term UI projects and i would dreaaam about doing it in squeak. My problem is that the targeted public won't like the morphic look, either the all-in-one-window design. After playing a little with wxSqueak, i realized that it was for me the perfect match of multi platform UI , cool Dev environment ...etc..etc.. I won't explain you all why Squeak is a great dev platform , will i ? Thank you in advance for the time you will take to think about :)

7 6

Spoon progress 30 January 2006: the initial Naiad user interface design
by Craig Latta 31 Jan '06

31 Jan '06

Hi-- Just a few notes about the current user interface for Naiad, Spoon's module system. Comments welcome (keep in mind that Matt Hamrick is working on security aspects, and I don't address them here). At the moment I'm about to perform the first HTTP-instigated synchronization of two object memories. The idea is... - The user starts a minimal Spoon system on localhost via a web browser (e.g., the 2003 "relief" demo, if you remember that). - That local Spoon system starts a webserver. - The user's web browser is redirected to the local Spoon's webserver; the user is greeted with a message saying that Spoon is running locally. - The user visits some other external website that lists available modules. Such a website has a bunch of URLs of the form "http://localhost:<port>/<command>", where <port> is some agreed-upon port on which each local Spoon web server listens, and <command> is a text-encoded bitstream that the local Spoon webserver understands. One of the commands is "load a module"; included in bits of such a command are the module ID (a UUID) and provider hostname/port for an available module. The local Spoon system, having received the command, makes a remote-message-sending connection to the providing machine, and synchronizes itself with a providing object memory. Initially the local Spoon system reports on the success of the command via its web server's responses; later, after the appropriate UI modules are loaded, it can just provide feedback with a normal GUI in its own separate host window. (There are other URL-delivered commands for quitting, making a snapshot, viewing currently-installed modules, etc.) thanks, -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

Jump to page: