seaside-dev May 2010

seaside-dev@lists.squeakfoundation.org

15 participants
22 discussions

Re: Metacello packaging
by Julian Fitzell 02 Jun '10

02 Jun '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

2 5

returnResponse: on seaside 3.0
by Hernan Wilkinson 31 May '10

31 May '10

Hi, is seaside 2.8 you could do something like this: self session returnResponse: (WAResponse document: aDocument mimeType: 'application/vnd.ms-excel' fileName: 'xxx.xls') that is, return in the response a specific content, in this case a csv report. How can I do the same with Seaside 3.0? I could not find it... Thanks Hernan.

3 3

testCodecLatin1 and testCodecUtf8Bom
by Michael Lucas-Smith 27 May '10

27 May '10

Hi All, #testCodecLatin1 and #testCodecUtf8Bom fail for me on VisualWorks.. once the Unicode string is created, #asByteArray is sent to it to "turn it back to bytes" but of course this is impossible, it's already a TwoByteString in VisualWorks and to turn that back to bytes, you need to specify an encoding using #asByteArrayEncoding: 'utf-8' (for example). Can these tests be written with a custom compare operation? the comment in #testCodecLatin1 explains the problem - that comparing unicode strings using #= is not necessarily going to work across platforms, but perhaps something like this might work everywhere: compare: a with: b a size = b size ifFalse: [^false]. 1 to: a size do: [:index | (a at: index) = (b at: index) ifFalse: [^false]]. ^true Cheers, Michael

3 7

Re: broken SU
by Nick Ager 26 May '10

26 May '10

I investigated this with Julian. Apologies for reiterating some of the ground already covered: SUAllComponentTests class>>initialize ..... preferenceAt: #scriptGeneratorClass put: *PTScriptGenerator* with a PTScriptGenerator anchors which contain an href and onclick handlers AND use "return false" in onClick to stop the href link from firing do not work as expected - The href link is activated. This is causing at least SUAccordion and SUCarousel to break in the current trunk. The problem can be fixed by replacing "return false" with "event.stop()". (WADispatcher default handlerAt: 'javascript/scriptaculous-components') preferenceAt: #scriptGeneratorClass put: nil results in working SUAccordion and SUCarousel without code changes. (WADispatcher default handlerAt: 'javascript/scriptaculous-components') preferenceAt: #scriptGeneratorClass put: nil and using the "event.stop()" code change also works. a potential problem arises for users, with existing Scriptaculous code that use say SUUpdater in an onclick handler on an anchor with an href. When they update to the latest code alls well provided they don't start using PTScriptGenerator, in which case they have to change their "return false" to "event.stop()" thoughts? Nick

1 0

broken SU
by Julian Fitzell 26 May '10

26 May '10

So I looked into the failing Scriptaculous code. The problem is that we are now adding onclick handlers for scriptaculous AJAX calls using the observe() function. Returning false from these handlers does not prevent the anchor's normal action from executing. Instead of "return false" you need "event.stop()". So, how do we solve that? We don't want users to have to know how Seaside is adding the event handler in order to know what code they need to write. Where's the right place to put an abstraction for this (and can it be shared between SU/JQ?). Do we define some variant of #callback: that doesn't allow the normal action to take place? (or a variant that takes a boolean - #callback:stop:?) I think we need to fix this before releasing because a bunch of the demos are just totally broken (at very least, we need to change all the "return false" statements to use "event.stop()" but that's not really a proper fix). Julian

1 1

Load order test failures
by James Foster 24 May '10

24 May '10

We have five errors starting with Core that seem to be fixed by Kom! Presumably something needs to be moved from Kom to Grease and Core. James Loaded Grease-Core-jok.34.mcz Loaded Grease-Pharo-Core-jok.18.mcz Loaded Grease-Tests-Core-lr.49.mcz Loaded Grease-Tests-Pharo-Core-jok.7.mcz 383 run, 380 passes, 2 expected failures, 0 failures, 1 errors, 0 unexpected passes GRUtf8CodecTest>>#testCodecUtf8 Loaded Seaside-Core-obi.630.mcz Loaded Seaside-Pharo-Core-lr.6.mcz Loaded Seaside-Tests-Core-lr.189.mcz Loaded Seaside-Tests-UTF8-lr.9.mcz Loaded Seaside-Tests-Pharo-Core-lr.9.mcz 816 run, 809 passes, 2 expected failures, 0 failures, 5 errors, 0 unexpected passes GRUtf8CodecTest>>#testCodecUtf8 WAGenericCodecTest>>#testGenericCodecMacRoman WAGenericCodecTest>>#testGenericCodecUtf16be WAGenericCodecTest>>#testGenericCodecUtf16le WAEncoderSqueakTest>>#testEncodedLatin1Url ... Loaded Seaside-Email-lr.15.mcz Loaded Seaside-Tests-Email-lr.9.mcz Loaded Seaside-Pharo-Email-lr.6.mcz 1404 run, 1397 passes, 2 expected failures, 0 failures, 5 errors, 0 unexpected passes GRUtf8CodecTest>>#testCodecUtf8 WAGenericCodecTest>>#testGenericCodecMacRoman WAGenericCodecTest>>#testGenericCodecUtf16be WAGenericCodecTest>>#testGenericCodecUtf16le WAEncoderSqueakTest>>#testEncodedLatin1Url Loaded DynamicBindings-lr.13.mcz Loaded KomServices-lr.20.mcz Loaded KomHttpServer-lr.52.mcz Loaded Seaside-Adaptors-Comanche-pmm.57.mcz Loaded Seaside-Tests-Adaptors-Comanche-lr.13.mcz 1412 run, 1410 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Comet-Core-lr.49.mcz Loaded Comet-Pharo-Core-lr.6.mcz Loaded Comet-Tests-Core-lr.10.mcz Loaded Comet-Examples-lr.18.mcz 1415 run, 1413 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes

1 2

Re: [Seaside Commits] Seaside 3.0: Seaside-Widgets-obi.18.mcz
by Julian Fitzell 22 May '10

22 May '10

Is this dependent on whether your week starts on Sunday or Monday? Julian On Sat, May 22, 2010 at 10:34 PM, < squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > Gerhard Obermann uploaded a new version of Seaside-Widgets to project > Seaside 3.0: > http://www.squeaksource.com/Seaside30/Seaside-Widgets-obi.18.mcz > > ==================== Summary ==================== > > Name: Seaside-Widgets-obi.18 > Author: obi > Time: 22 May 2010, 9:38:04 pm > UUID: ee5cf2e1-fc76-694e-9691-4638a0e50294 > Ancestors: Seaside-Widgets-jok.17 > > - fix http://code.google.com/p/seaside/issues/detail?id=558, > WAMiniCalander displaying incorrectly when the month begins on Sunday > > =============== Diff against Seaside-Widgets-jok.17 =============== > > Item was changed: > ----- Method: WAMiniCalendar>>weeksDo: (in category 'private') ----- > weeksDo: aBlock > | day nextMonth | > day := Date newDay: 1 month: (Date nameOfMonth: self monthIndex) > year: self year. > + day := day subtractDays: (day dayOfWeek - 1). > - day := day subtractDays: day dayOfWeek. > nextMonth := (self monthIndex \\ 12) + 1. > [ day monthIndex = nextMonth ] whileFalse: [ > aBlock value: day. > day := day addDays: 7 ]! > > > _______________________________________________ > commits mailing list > To unsubscribe, email commits-leave(a)lists.seaside.st > http://lists.seaside.st/listinfo/commits >

2 2

Seaside 3.0a6ish
by Michael Lucas-Smith 22 May '10

22 May '10

As it stands right now, the only tests that are failing for VisualWorks 7.7.1 are the three codec tests (one of which is expected to fail on VisualWorks): GRCodecTest>>testCodecLatin1 GRUtf8CodecTest>>testCodecUtf8Bom GRUtf8CodecTest>>testCodecUtf8ShortestForm (expected to fail) The reason for these failures was raised in a previous email. Cheers, Michael

5 19

improving rendering performance (on Pharo)
by Philippe Marschall 22 May '10

22 May '10

Hi While hacking on an encoding prototype I found a way to improve Seaside rendering performance on Pharo. We spend quite a lot of time in WAEncoder >> #nextPutAll:. I realized I could use the same trick we use in for UTF-8 encoding. Most of the content we don't have to escape so if we can quickly decide that we don't need to escape the contents we can just do a #nextPutAll:. Pharo has a primitive for exactly this. So how much is it worth? The somewhat synthetic Seaside Performance Index goes through the roof (before [1] after [2]) and WALotsLinksFunctionalTest goes from about 900ms to about 500 ms. The code is in Grease-Core-pmm.38, Grease-Pharo-Core-pmm.20, Seaside-Core-pmm.636. Right now the code is hacked in and has a slow default fallback on GRPlatform. I believe I could make it a bit faster for cases where only very little content needs to be escaped (think a huge text block with a single & in the middle). The question is where we go from here, in the end we pretty much have methods for escaping XML and URL in platform with the current implementation on GRPlatform as fallback. [1] http://imgur.com/FftPH.png [2] http://imgur.com/qlivp.png Cheers Philippe

3 7

Newlines in Javascript / JSStream
by Michael Lucas-Smith 20 May '10

20 May '10

Hi All, I thought this was addressed in a previous with the introduction of GRPlatform>>newline, but it appears that my particular issue wasn't addressed. When I transmit smalltalk strings to the client via javascriptOn:, the Smalltalk newline convention doesn't get converted to the unix newline convention (which is the convention for javascript). And the opposite is too true, when I transmit a string using JSON back to Smalltalk, the unix newline doesn't get converted back to the Smalltalk newline convention. Does any one know what happened here? #newline was added but then not actually used? Michael

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev May 2010