seaside May 2010

seaside@lists.squeakfoundation.org

66 participants
89 discussions

Installing and testing Seaside 2.8.4, Magritte and Pier in Pharo 1.1
by Mariano Martinez Peck 03 Jul '10

03 Jul '10

Hi seasideers. I was loading all this stuff of PharoCore 1.1 and see if everything seems to be working. At this is the case :) However, I have 2 tests with errors and this is due to send to BlockClosure >> fixTemps which is deprecated in Pharo 1.1 The fix is easy, just remove the send of fixTemps, but I am not sure the impact of this in other dialects. But would be cool not to have the deprecated warning when loading. The places are Amb >> oneOf: aCollection and Amb >> valueOfOneOf: blockCollection Then I have two failing but I don't understand why: WABacktrackingTest >> testOrderedCollection I don't know why here, but after "original removeLast." snapshot has the elements "1" and "nil" instead of "1" and "2", and thus, it fails in self assert: original asArray = #(1 2) The other is: WABacktrackingTest >> testDictionary It is failing in "self assert: (original at: 1 ifAbsent: []) = #a." because original shows -> a Dictionary(2->#b 3->#d ) I know your effort is now in Seaside3 but having all green tests with Pharo 1.1 would be really cool :) Last thing, if you want to test it, just take a PharoCore 1.1 image, for example: https://gforge.inria.fr/frs/download.php/26995/PharoCore-1.1-11357-UNSTABLE… And then evaluate: (Smalltalk at: #Gofer) new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside'; load. ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. and run tests :) Thanks Mariano

7 9

Menu component?
by Gabriel Cotelli 10 Jun '10

10 Jun '10

Hi, Anybody knows if there's some menu component available ? Something like http://apycom.com/menus/7-lime.html (ignore the fancy effects... by now my focus is on the menu functionality) Thanks in advance, Gabriel -- Gabriel O. Cotelli ------------------------------------------------- Desarrollo y Tecnología - Mercap S.R.L. Tacuarí 202 - 7º Piso - Tel: 54-11-4878-1116 al 19 Ciudad Autónoma de Buenos Aires - Argentina http://www.mercapsoftware.com ------------------------------------------------- Este mensaje es confidencial. Puede contener información amparada por el secreto profesional. Si usted ha recibido este e-mail por error, por favor comuníquenoslo inmediatamente via e-mail y tenga la amabilidad de eliminarlo de su sistema; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias. This message is confidential. It may also contain information that is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by e-mail immediately and delete it from your system; also you shouldn't copy the message nor disclose its contents to anyone. Thanks.

3 4

[ANN] ConfigurationOfSeaside28 version 2.8.4.6 available
by Dale Henrichs 04 Jun '10

04 Jun '10

new version of ConfigurationOfSeaside28 available in http://www.squeaksource.com/MetacelloRepository. I've tested the configuration on Pharo 1.0, Squeak 4.1, and GLASS 1.0-beta.8.

3 5

[ANN] First cut at a CKEditor on Seaside 3.0
by John Pierce 01 Jun '10

01 Jun '10

Hi all, I've posted on SqueakSource my first cut of CKEditor version 3.3 running on Seaside 3.0. Visit ckeditor.com/demo to see this very nifty HTML WYSIWYG editor that can be used for all sorts of applications. I'm gonna be folding CKEditor into an application I'm doing, but I decided to keep this Seaside component separate due to it's versatility to be used in many apps. Anyways, project on SqueakSource is called SeaKEditor. Cheers, John If you can find a path with no obstacles, it probably doesn't lead anywhere. -- Frank A. Clark

3 2

concatenate JS assignments in script generation
by Johan Brichau 31 May '10

31 May '10

Hi, I'm a bit puzzled with one of the JSScript features in Seaside 3.0. I'm trying to generate something like the following javascript: var1 = function() { ... }; var2 = function() { .... }; Using the following Seaside code: script1 := ( ... ) asFunction assignTo: 'var1'. script2 := ( ... ) asFunction assignTo: 'var2'. ^ script1 , script2 However, the concatenation in the return puts all statements of script2 into the body of script1, rather than concatenate the assignments. The result is thus: var1 = function() { .... ; var2 = function() {...} } Variables script1 and script2 indeed contain a JSFunction object which is decorated with a JSAssign. So I must be missing something on how this decoration is supposed to work. Hope somebody can help me :-) cheers! ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

3 2

Iterating through list - callback
by recursive68＠gmail.com 31 May '10

31 May '10

Thanks Julian, for the info and fixes, it's now working correctly. Cheers Jon

1 0

Iterating through list - callback
by recursive68＠gmail.com 31 May '10

31 May '10

Hi, I'm trying to iterate through a resultset from a MySQL query and although it's displaying the users as required when I click on the anchor it always deletes the last user in the list rather than the one selected: rs := slotquery rset. [rs next] whileTrue:[ user:= rs valueNamed: 'name'. html text: user. html anchor callback: [self deleteUser:user]; with:' Delete'. html break. ]. It seems the anchor callback always uses the last assignment to user, where am I going wrong ? Thanks jon

2 1

[ANN] Camp Smalltalk London filling up
by Julian Fitzell 30 May '10

30 May '10

Much to our delight, there seems to be a lot of interest in the Camp Smalltalk event in London. We originally estimated our capacity at 30, and those slots have already filled up in less than 4 days! We are just now discussing what our actual maximum capacity is. We'll be able to handle a few more people, we're just now sure yet how many. So if you're interested in coming and haven't signed up yet, please head over to cslondon2010.eventbrite.com and add yourself to the waiting list. That will really help us understand how many more people still want to attend. Note that joining the waiting list does not commit you to attending, so if you're still on the fence, you might want to sign yourself up anyway. We'll open up some more spots next week and then see how it goes. Thanks for your enthusiastic participation! Julian

1 0

Re: Metacello packaging
by Julian Fitzell 29 May '10

29 May '10

(whew.... too long. if this keeps up, we'll have to wait until ESUG to do this in person :) ) On Sat, May 29, 2010 at 9:36 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > Julian Fitzell wrote: >> >> On Sat, May 29, 2010 at 12:32 AM, Dale Henrichs <dhenrich(a)vmware.com> >> wrote: >>> >>> To directly answer your question...I agree, loading Grease should not >>> load >>> Slime by default and yes, Slime can certainly be in it's own Metacello >>> configuration (not package:). >> >> Looking at the Metacello chapter PDF that's circulating, it looks like >> what I meant was "project". Are you sure these things want their own >> configurations? It seems to me that Slime is "part of" Grease and all >> those other packages are "part of" Seaside, they're just not part of >> the core. Again, apologies if I'm just misunderstanding the >> terminology or the repercussions. > > Project and configuration are very similar in meaning, When I say > "configuration" I am specifically referring to a "ConfigurationOf package". > > In my opinion I think that "these things" do want their own configuration. > That is why I mentioned them:) However, the confguration vs group decisions > should be made by the developers themselves since that structure influences > how users of the configurations/groups view the project. > > From my perspective Slime is built on top of Grease rather than being a > fundamental part of Grease. Grease is supposed to be a portability layer > and Slime doesn't implement portability methods. Slime is a tool that is > used to analyze the portability of a body of code, but at the moment Slime > itself has not been ported to either Squeak or GemStone nor is it _required_ > for "Grease" functionality on the other platforms. > > So from that perspective Slime could be separated out into a separate > configuration without affecting the basic functionality of Grease as a > portability layer. I think Slime is quite fundamental to Grease from a developer's point of view. Because we can't reasonably test all valid behaviour, it's equally important to know the things you *can't* do. Would you feel differently if Slime was called Grease-Tests-Bad? That's how I think of it conceptually. >From the point of view of someone loading Grease as a compatibility layer for something they just want to run, though, clearly they don't need Slime. They might not even need the Grease tests, of course. I guess in my mind, for the average user choosing to load Grease, they should be getting Slime included on any platform that supports it. But there needs to be a slimmer set of packages (maybe it's just Grease-Core itself) that projects which use it can pull in. > In the end it is a judgment call as to when a chunk of functionality should > be split out separately, because in terms of pure functionality the > following two statements end up loading _exactly_ the same packages: > > ConfigurationOfSlime project latestVersion load. > > ConfigurationOfGrease project latestVersion load: 'Grease-Slime'. Agreed. > The factors that I think drive one towards choosing a configuration over a > group are: > > 1. how independent is the chunk of functionality? > - does the chunk of functionality have a utility outside of the > original project? > - does the chunk of functionality have an identity independent of > the original project? > - if either of the above are largely true, then a separate > configuration may be a good choice > 2. how critical is the chunk of functionality to the project? > - is it an option or an addon, where an "option" is something that > you have to choose one from many and an "addon" is something that > can be completely left off without affecting functionality? > 3. how heavy weight is the chunk of functionality? > - an addon that is complex in terms of the number of individual mcz > files or in terms of "required projects" may be easier to manage > if it is in its own configuration > 4. how tight is the coupling of the chunk of functionality? > - if the chunk of functionality is tightly coupled to the "core" > then it makes sense to embed the functionality in main > configuration And also, 5. how hard is it for people to know where to look for stuff? - if there are projects within a configuration you can look through the options - how do you know where to start looking for other configurations that might work with the one you're loading? And 6. how is the group of code branded? - if the combined functionality is considered to be distributed together, it may make sense to have it in a single configuration > I think that you went through a similar decision process when you originally > split Grease out from Seaside. > > In my opinion Slime should be separated out for points 1 (outside > functionality and independence), 2, and 3. In my world view, I think 1,2, and 3 actually argue for keeping Slime in the ConfigurationOfGrease. I can't see anyone using it without Grease, I think people should be loading it when working with grease, and its configuration is pretty simple, no? But that's just my image of it - I'm happy to hear alternate views. > For the Javascript chunks (Javascript, JQUery, Prototype and Scriptaculous) > I think the strongest arguments are points 2 and 3 ... I don't know about 4 > as for point 1, they don't have much utility outside of a Seaside context so > I would lean toward using a group with the caveat that point 3 could be a > reason for moving them all into a ConfigurationOfSeasideJavascript... > > RSS seem to me to be candidates because it is more like an addon. I mean, sure, I guess. But it's a single package, so why have a separate configuration? And I still worry about 5. Ok, let me put it another way: if it's an addon (and maybe it is), let's move it to the Addons repository (actually, I'm liking that idea). If we're bundling it by default in the Seaside distribution, I'd argue for keeping it in the same Configuration. > Comet could be called a group because of point 4. I guess I'd make the same argument as for RSS. > So the first order decision would be are any of those chunks candidates for > separate configurations or not ... in your opinion? I'm really just going on a gut feeling here, which is a dangerous place to be when I really don't know Metacello very well :). To me, if you have to namespace the configuration name (i.e. it's ConfigurationOfSeasideJavascript not ConfigurationOfJavascript) it feels a bit forced to have a separate configuration. "Seaside" to me is more or less what we distribute in the one-click, so in my opinion most of the stuff you mention should be in ConfigurationOfSeaside, due primarily to 1, 5, and 6. > What packages do you consider part of the Seaside-Base and where does > Seaside-Environment fit in? :) Ah... Environment. That wart keeps changing. Looking at the dependencies right now, we seem to be in a state where I would basically consider Environment plus its dependencies to be "Base". "Base" should be everything that basically everyone uses and nothing that opens ports, registers applications, or pulls in extra dependencies. So no Tests, no dev tools, no OB tools, no examples, no welcome screen, etc. Arguably Base should *not* include Environment itself, but let's not get too complex for now. So that's where I stand. I don't think my opinion is necessarily more relevant though: I certainly know the package structure well, but you know the packaging tool! And maybe a fear of multiplying Configurations is my own personal hangup. By the way, I changed the message subject and added seaside-dev - probably best to continue the discussion there rather than on the general seaside list. Julian

1 0

[Fwd: Re: [Moose-dev] Re: why Glamour configuration is loading Refactoring and all the rest?]
by Dale Henrichs 29 May '10

29 May '10

Tudor, I replied last night but my reply to Moose list bounced... -------- Original Message -------- Subject: Re: [Moose-dev] Re: why Glamour configuration is loading Refactoring and all the rest? Date: Thu, 27 May 2010 17:16:29 -0700 From: Dale Henrichs <dhenrich(a)vmware.com> To: Mariano Martinez Peck <marianopeck(a)gmail.com> CC: Related to the development of Moose and other related tools <moose-dev(a)iam.unibe.ch> References: <C70F7B35-4F97-4437-9760-E1916A8DCBE8(a)inria.fr> <AANLkTik9a_pyLToaHZuFEJIlLi601Dk-AqlFRZwjzY7X(a)mail.gmail.com> <AANLkTinNTjJG7lp_GbW0UHt5ytfu1_5N-uHyfm3-uud8(a)mail.gmail.com> <AA66B7BA-0C67-46DC-9B5F-37387163FCEF(a)inria.fr> <5A6D62FD-2C96-4A23-A982-1C6512EDBA8E(a)gmail.com> <AANLkTik0ljGZMsSPpFrMroDZhTyz0Oet0XQ1eLZrzkJr(a)mail.gmail.com> Mariano, Refactoring-Core is used by SLIME and SLIME is unconditionally loaded for Seaside3.0 ... I think that for at least the short term it was decided that loading _ALL_ of Seaside3.0 was better than having folks random pieces ... by default Magritte2 loads Magritte-Seaside which pulls in the whole enchilada. You can just arrange to have just Magritte-Model loaded (without Magritte-Seaside) by just loading #('Magritte-Model')... Dale Mariano Martinez Peck wrote: > dale? > > On Thu, May 27, 2010 at 8:47 PM, Tudor Girba <tudor.girba(a)gmail.com<mailto:tudor.girba@gmail.com>> wrote: > I do not know. This is what the ConfigurationOfGrease says: > > > ConfigurationOfGrease>>version10alpha91: spec > ... > spec project: 'Refactoring-Core' with: '1.3'. > > Cheers, > Doru > > > On 27 May 2010, at 18:56, Stéphane Ducasse wrote: > > +1 > > On May 27, 2010, at 2:58 PM, Mariano Martinez Peck wrote: > > > > On Thu, May 27, 2010 at 12:51 PM, Tudor Girba <tudor.girba(a)gmail.com<mailto:tudor.girba@gmail.com>> wrote: > Glamour is loading Magritte which loads Grease which loads the RB. Is this a problem? > > Seeing completely from outside and without knowing anything, I don't understand why Grease, as a compatible layer framework (or whatever it is) should load RB by default. > > Cheers > > Mariano > > > > Doru > > > On Thu, May 27, 2010 at 11:25 AM, Stéphane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch<mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch<mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch<mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch<mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com<http://www.tudorgirba.com> > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch<mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >

4 13

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside May 2010