Squeak-dev January 2002

squeak-dev@lists.squeakfoundation.org

176 participants
612 discussions

[FIX] httpHack-ls
by Lex Spoon 30 Jan '02

30 Jan '02

This partially fixes Goran's difficulties using Scamper to talk to SqueakDot. You also need some sort of cookie support; people interested can look at: http://coweb.cc.gatech.edu:8888/cs2340/uploads/cookies.1.cs as a basis for cookie support. from preamble: "Change Set: httpHack-ls Date: 30 January 2002 Author: Lex Spoon Quickly fixes some errors in the HTTP code. It's still a mess, and probably has many more errors."!

1 0

[FIX] progressBeGone-ls
by Lex Spoon 30 Jan '02

30 Jan '02

from preamble: "Change Set: progressBeGone-ls Date: 30 January 2002 Author: Lex Spoon Make the notifier from an informUser:during: call go away, if there is an error and the debugger is closed."!

1 0

[BUG][3.3]Deleteing Worlds Of Squeak Project
by Bijan Parsia 30 Jan '02

30 Jan '02

First, kudos for all and sundry for general and specific wonderfulness. I don't think I mentioned in a while how nice it is to be able to download an uptodate test pilot image *all the time*. One of the cool bits of community coordination and volunteerism. Second, I've had trouble for a while with deleting the "Worlds of Squeak" window, which I routinely do. But in 3.3, I actually get a debugger from ImageSegmetn>>rootsIncludingPlayers. The error is "only look in local env, not up chain". this seems like a module problems :) Note, I invoked it just by clicking on the close box. The comment right after the error code says: It strikes me, looking at Project>>okToChange, that it is a fine candidate for a registery system :) Cheers, Bijan Parsia.

1 0

Polls are here! Re: Next chapter on SqueakDot!
by goran.hultgren＠bluefish.se 30 Jan '02

30 Jan '02

The day is coming to an end here in Stockholm. I wrote: > Coming up next > ================== > > Let me make my little charter for the ultra near future, I want you all to be in the loop: > > 1. First I am adding simple Polls so that the site actually can be useful. Thats good. :-) Well, ok, polls are there in the first simple incarnation! - Anyone with an account can add as many polls he/she wants. Take it easy. - You set how many days it will be valid. It shows up for voting on the top page if it is still valid. - Right now anyone can vote and I don't use cookies or anything so you can vote multiple times.... :-) - The available choices are currently Yes and No, but I will fix that of course. I will also add the option of having polls for "members only" and other features you can come up with that sounds useful. > 2. Improve the architecture a little bit hiding the HTML somewhat. Haven't had time to do that yet. Will get back to this tomorrow and plan to release full changesets at the end of tomorrow. regards, Göran PS. If someone lost an account it was my fault - but I think I saved them... DS

1 0

re: Squeak VM, real-time I/O, and threading
by Craig Latta 30 Jan '02

30 Jan '02

(Phooey... I sent this message prematurely before...) Hi Goran-- ('Sorry for the narrow quote width... I'm on a handheld and haven't implemented automatic quote-filling yet:) > What about license then? Heard > some rumour before that Flow is > under LGPL? (John Sarkela had asked me last year how I wanted to licence Flow, and I answered LGPL.) > I downloaded the latest zip but > found no license at a cursory look. 'Sorry about that... I didn't specify licensing details because I hadn't decided (and I was comfortable with the default legal standing in the interim). > If I remember the latest "license > threads" correctly we (the > community) pretty much agreed > that stuff that counts as "base > image" (when modules arrive; I > guess some modules will be > officially dubbed as "base" > modules) should be released under > SqueakL (at least). Currently, I lean toward licensing Flow under the recipient's choice of the Squeak license, LGPL, or a license I plan to write that more accurately expresses my desires (I have no qualms about adding yet another license to the universe :). So I assume Flow will enter Squeak under the Squeak license. > I like Flow a lot even if I have a few > itches about it (only nitpicks but > anyway, as the author you > probably want any feedback you > can get): Yes, thanks! > 1. I personally don't like the added > methods in Boolean like > #yourselfUnlessFalseDoFirst: . I > had to stare and check and think > and almost still didn't get it! ;-) My > advice: Get rid of those. :-) Hmm, they seemed straightforward and useful to me at the time. :) I'll take another look... > The Client/Server classes built for > reuse by inheritance would be > easier to use, I think, if > constructed for reuse by > composition. I think that's probably true... I tend to defer such specialization until the complexity gets to a certain point, and I felt I hadn't reached that point with the client/server modeling yet. > And just to make things clear, the > reasons I abandoned Flow was that > it ISN'T in the base image and thus > currently suffers from that. Right... Although I'm interested in making Flow convenient to use for everyone, I'm encouraged by the potential for a distributed module system to make inclusion in a particular snapshot less of an issue. I think modularity will also help the sync problem too. thanks again, -C

1 0

RE: Challenge- large files - LDAP
by Mark Mullin 30 Jan '02

30 Jan '02

I saw Yoel make a comment on reading LDIF entries. Not really my field of expertise, but when I implemented the ADO bridge for Windows (you can stop here if you're using a reliable non-market dominating system) I discovered a number of interesting sources, including LDAP if you're on 2K. In that case, you could use a plugin to read and return the data to squeak, we've found with this approach and a simple database, we can bloat up our image by 100Mb or so in a minute or so. As I said before, Squeak isn't the worlds greatest __simple__ collection manager. The variety of collections is wonderful, but the performance speed of iterated OrderedCollections isn't so. At the end of the day though, after 20 years of snarling at the man, now I agree with Peter Deutch. Buy a bigger machine or solve that part of the problem differently :-) Mark

1 0

RE: [Challenge] large files smart compare (was: Re: Squeak for I/ O and Memory Intensive tasks )
by Oca Emilio 30 Jan '02

30 Jan '02

> That reminded me - GemStone is available "free for personal use" I think > AND there is an interface to it for Squeak! Yep. Those people in > Argentina have been busy... Yeah, We've been busy, thas the way we live (or survive) here :(

1 0

[BUG] In Scamper
by goran.hultgren＠bluefish.se 30 Jan '02

30 Jan '02

Just discovered that Scamper has a problem logging in on SqueakDot. It seems to append a $? before the fieldname 'password' when POSTing the form. Since I am looking for the field named 'password' and not '?password' it fails miserably. Haven't looked in to it yet. regards, Göran

1 0

Re: squeakdot and seaside
by goran.hultgren＠bluefish.se 30 Jan '02

30 Jan '02

Avi Bryant <avi(a)beta4.com> wrote: > Sigh, I was hoping I would get to bed before anyone would reply to this. > I'll respond quickly now, more fully after I've had some sleep. I am in Europe so its early here... :-) > Goran writes: > > >My next improvements move a bit in this direction but my motivation for > >those improvements is not so much that I want to separate the webtech > >from Smalltalk in order to have different programmers working on them. I > >just don't really think that is feasible. > > Whether or not it's feasible to have different programmers working on them > from the start, it was a major design goal for me that you should be able > to tweak your templates with Dreamweaver or some such tool at any point in > development - so that you can at least have the designers work on the > HTML once the basic skeleton is there without any conflicts. We take this > fairly far - for example, the only addition to HTML the framework requires > is that every dynamic element must be assigned an id, and the simplest way > to do that looks like, for example > > <input iowa:id="firstName"> > > but the parser also treats any attribute starting with an @ sign as the > id attribute, so > > <input name="@firstName"> > > would also work. This is to take advantage of the way WYSIWYG editors > provide dedicated edit boxes for certain attributes of certain elements - > just stick the ID wherever it's convenient. (This isn't actually built > into the parser, btw, but it's one of the standard macro expansions that > gets run - and yes, you can add your own). Nice. Hmmm. Separation is of course good in itself as long as it doesn't make things too "secret". > >Another thing - you have bindings, Swiki (at least the old one) had > >something called UrlMaps, the Java Tomcat world > >has these things too. I decided to NOT have any bindings (simpler and > >less places to change) of urls onto methods > >and instead equalize the url path with the method names on the View > >instances. Jury will tell. > > The urls are actually all generated by the framework, so the mapping > isn't as simple as between urls and method names. However, I think the > default bindings provides something similar to your direct method mapping. > For example, > > <a href="@delete:">Delete Item</a> > > will create a link with an ID of "delete:" - this will default to being > bound to the #delete: method. However, if for some reason you need to > change the default, you can specify in the bindings > > (template elementNamed: 'delete:') > set: #action toMethod: #remove: > > One major reason you might want to do this is if the method it should be > bound to changes depending on context. This is less common for method > bindings than for most others, however, and I think I almost always just > specify the name of the method in the html. Ok, sounds good. In this respect our two frameworks both still suffers slightly from the fact that we need to synch the ids in the HTML with the code. Info in two places. Currently I have my "ids" mostly in the same method that is "named". Which means that even though its info in "two places" (both in the HTML and the method name itself) it's easy to keep them in synch. I wonder how this could be even more improved... > >> removeItem: anItem > >> (self confirm: 'Are you sure you want to remove the item ', anItem) > >> ifTrue: [items remove: anItem. self inform: 'Item removed'] > > >Now, this is cool. I think Stephen Pair described a similar feature to > >me at the last OOPSLA. > >Hmmm. This can have both positive and negative sides, no? > > >+ Cool. And neat. Hides the Http flow of requests from the developer. > >- Sneaky. Hides the Http flow of requests from the developer. > > I don't think of it as hiding the http flow - who *cares* about the http > flow? Well, I do! :-) What I meant is that I have been burnt earlier by 4GL tools, complicated frameworks etc. that tries to hide too much and thus only "trips me up" because it does a lot of smart things behind my back. It all depends of course on how good it's implemented. My framework tries to be really "concrete" in that it doesn't try to hide anything really. Well, some things I will try to "hide" (HTML stuff) but not the flow I think. "HttpView" requires some knowledge on how things "work" in webland. But I hope that will turn out to be a strength somehow! :-) > What it does is brings the actual *program* flow to the fore, True. > which is much more important. (In case it wasn't obvious, I've long since > given up any idea of being lightweight/bare metal anyway. HTTP is just > too low level to be interesting). Well, this is probably where we differ a bit in "design". But both approaches are interesting for different tasks. My framework (or similar ones) might be nice if you are doing simpler stuff and yours if the system is more complex. > >> - pages or entire applications can be embedded as subcomponents within > >> another page, or wrapped around them. This allows complex widgets like > >> trees, tabs, navbars, etc to be built and reused. Subcomponents use the > >> same transparent bindings system as form elements to sync data with their > >> parent page. > > >Ah, yes, a bit like what I was aiming for. Do you have this part working > >today? > > All of what I described works today. If you want to know what'll work a > month from now, that'll be a whole other list... ;-) Nice! Again - this sounds like a really nice framework. It would be interesting to build some simple "demo apps" in both our frameworks and then study strenghts and weaknesses. > Ok, time to sleep. > Avi Sure! I am going to lunch. :-) regards, Göran

2 1

Next chapter on SqueakDot!
by goran.hultgren＠bluefish.se 30 Jan '02

30 Jan '02

Wow, I am awed with all the interest! If only for that, is was worth doing this "publish" so early when almost nothing works. ;-) New since yesterday ======================== 1. Added "My SqueakDot" - the account page. This is where you can access all the state of your personal instance of SDAccount living in the server. 2. Added checkpointing of accounts. Each account gets a filedirectory on the server and in that directory the instance of SDAccount is stored as an export ImageSegment. 3. Added revert to last checkpoint. When the server restarts it loads the accounts from the last checkpoint. 4. Added the analysis page which uses ImageSegments to present some info about the structure etc. Checkpointing together with Image saves will have to do for now as persistence mechanism. Checkpointing of accounts should be automatic regularly. Image save likewise. It's simle and sure, the server can loose stuff since it doesn't secure it to secondary storage right away, but this is a compromise making it very easy to add new objects to the SDAccount without having to think about storage. Coming up next ================== Let me make my little charter for the ultra near future, I want you all to be in the loop: 1. First I am adding simple Polls so that the site actually can be useful. Thats good. :-) 2. Improve the architecture a little bit hiding the HTML somewhat. 3. Post it all as neat changesets for 3.2 on the list for anybody to tinker with at home. 4. Focus on getting the "development" stuff working - enable SqueakDot for multiple developers. The idea is to get all you guys in there ASAP because that will boost this thing I think. 1-3 might be done today if I am lucky. Or at least tomorrow. Number 4 is the one I really would like help with. Please - help me and come up with improvements to my draft on that. :-) What I would like SqueakDot to become ============================================= 1. A playground for the HttpView framework. I want everything to be inspectable (like the links to the source on the pages etc). 2. A place for different webbased services to the Squeak community. First out is support for Polls since we have had trouble conducting those on the mailinglist. Other things that comes to mind is something similar to Freshmeat (catalog of Squeak modules) or some sort of simple task management for SqF etc. One thing that I do NOT think that SqueakDot should do though is to have forums (like Slashdot has, which may suggest that the name was pretty stupid...) because I do not want to compete with the mailinglist. This is IMPORTANT. The mailinglist should continue to be the heart of the community IMHO. 3. Experiment in highly concurrent development in Squeak. My little draft on that is still sketchy but I want to mimic the directness of a Wiki/Swiki in Squeak development. It should be very easy to add a feature to the site for anyone capable of doing so and being trusted with a developer username and password (which you can't get just like that) and there should be no "review bottlenecks". Ok, over and out. regards, Göran

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
62
Older →

Jump to page: