seaside-dev December 2008

seaside-dev@lists.squeakfoundation.org

11 participants
128 discussions

exception handler instance creation
by Julian Fitzell 04 Feb '09

04 Feb '09

I started writing some docs on the new exception handler interface. In doing so, I realized I hated the method name #exceptionToCatch so I changed that and then remembered that Lukas was asking for the exception handlers to implement #handles: and #, so that they can be used in place of an ExceptionSet as defined in the ANSI spec. So I did this too. This raised again the question of when an instance of our exception handlers should be created. If you look at the current implementation of #handleExceptionsDuring:context:, you will see that an instance is not actually created until an exception that this class handles is signaled. This requires a temporary variable and means that the instance does not have a chance to indicate whether it wants to handle the exception or not (whether they is a required feature or not is perhaps debatable... I dunno). The only reason I did this was to avoid the overhead of creating the instance when we don't need it but I'm wondering if this was a premature optimization and the implementation would be simpler if I didn't do it. #handleExceptionsDuring:context: would just become: #handleExceptionsDuring: aBlock context: aRequestContext ^ (self context: aRequestContext) handleExceptionsDuring: aBlock And on the instance side we would have: #handleExceptionsDuring: aBlock ^ aBlock on: self do: [ :exception | [ self handleException: exception ] on: Error do: [ :error | self internalError: error ] ] No temporary variable, instances can choose whether to handle exceptions if they want to, no risk of being unable to create an error handler when reporting an internal error. Am I right that this seems like the better option? Julian

4 8

Re: [Seaside-dev] basicNew
by Avi Bryant 07 Jan '09

07 Jan '09

On Mon, Sep 29, 2008 at 12:43 PM, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote: > Avi> Change super to self in this method, and (given the rest of the code > Avi> in my example) you would have infinite recursion. > > I didn't see that you had a local initialize. If you had, then > *it* should have been the one to have super initialize, since the local > initialize is superceding it by extension. And what would the rest of that method look like? What would the other methods look like? This is a fairly intricate convention and it doesn't make sense to look at an individual piece of it in isolation. If you're arguing that the local initialize should call its super method, can you also show what the rest of this (tiny) example would look like so I can understand the entire control flow you're proposing? Avi

6 14

Issue 266 in seaside: remove uses of generic Error
by codesite-noreply＠google.com 31 Dec '08

31 Dec '08

Comment #1 on issue 266 by philippe.marschall: remove uses of generic Error http://code.google.com/p/seaside/issues/detail?id=266 +1 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 161 in seaside: document error handling
by codesite-noreply＠google.com 30 Dec '08

30 Dec '08

Updates: Status: Fixed Comment #5 on issue 161 by jfitzell: document error handling http://code.google.com/p/seaside/issues/detail?id=161 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 161 in seaside: document error handling
by codesite-noreply＠google.com 30 Dec '08

30 Dec '08

Comment #4 on issue 161 by jfitzell: document error handling http://code.google.com/p/seaside/issues/detail?id=161 http://blog.fitzell.ca/2008/12/seaside-29-exception-handling.html I'm just trying to get onto seaside.st to post a link to it but it's being unresponsive... -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

[ANN] Seaside 2.9 Alpha 2
by Lukas Renggli 30 Dec '08

30 Dec '08

Over a month has passed since the last release of Seaside 2.9. We are very pleased to announced Seaside 2.9 Alpha 2 as a next step towards the release of Seaside 2.9. We've mainly worked on two things: (1) closing critical issues that have been collected in the bug tracker, and (2) making different configurations of Seaside a snap to load. 1. Closed Issues ================ - Issue 3: A RESTful configuration editor would be very useful - Issue 87: ColorValue>>hex fixes - Issue 126: review request handler documentation - Issue 165: consider WAPainter refactoring - Issue 193: do we really need #vmStatisticsReportString? - Issue 200: Seaside 2.9 project page on SqueakSource outdated - Issue 206: check weird #value call on block in WADebugErrorHandler - Issue 211: deprecate the scriptcaulous convenience methods on Canvas - Issue 216: RSS Changes demo produces invalid XML - Issue 218: WADispatcherEditor doing a #call: in #initialRequest: - Issue 219: Why does WADecorationTask override #updateStates: ? - Issue 227: #halt should always halt - Issue 228: Move the Swazoo server adapter over to WAServerAdaptor - Issue 234: Source code view is broken after painter refactoring - Issue 240: JSJsonTests are not portable - Issue 241: WANumberPrinter>>#digitsOf:base: uses a Float as an Array index - Issue 242: Using a niladic actionBlock with on:do: in not portable - Issue 245: WAHalo Source View is broken - Issue 246: Anchor callbacks should not accept blocks with one argument - Issue 249: WATree broken in example browser - Issue 250: JQuery Droppable does not seem to work right - Issue 251: Accepting code in the browser opens a deprecation warning in Pharo - Issue 254: Sourceview via halo does not seem to work - Issue 256: Setting the default entry point does not seem to work - Issue 258: Bad XHTML for versionuploader - Issue 259: Request modification to WAPlatformTest>>#testIsResumable ... and uncounted enhancements to the core code and various other optional packages such as JQuery, JQuery-UI, Swazoo Server Adapters, etc. We've further improved portability to other Smalltalk dialects, in this round we mostly focused on VA Smalltalk. 2. The Seaside Builder ====================== We are proud to announce the Seaside Builder, the tool that makes it a snap to load a specific set of Seaside 2.9 packages into any recent Pharo or Squeak image: http://builder.seaside.st The Seaside Builder lets you either select a predefined configuration of Seaside packages or manually choose the packages you need. The builder automatically ensures that all prerequisites are selected and loaded in the right order. For the first time it is possible to conveniently choose between the MIT licensed Comanche or the LGPL licensed Swazoo web server. At the bottom of the page there are two download options available: "Load Script" creates a change-set that can be dragged onto any image causing it to load the selected Seaside packages. There is also the possibility to download a "Monticello Configuration" of the selected packages. In the future more download options might become available. 3. Things to be aware of ======================== First of all, it is important to remember that this is an Alpha release and therefore might not be suited to be used in production. We are however rapidly approaching the beta phase and disruptive changes are unlikely. Some of the core team members are already using Seaside 2.9 in production. You'll find a list of current migration issues at http://seaside.st/documentation/migration/28to29. 4. When things go wrong ======================= If you run into problems or encounter problems, please let us know using the issue tracker at http://code.google.com/p/seaside/issues/list or through the mailing list. We are especially interested into feedback concerning "The Seaside Builder". -- Lukas Renggli http://www.lukas-renggli.ch

2 1

Issue 266 in seaside: remove uses of generic Error
by codesite-noreply＠google.com 30 Dec '08

30 Dec '08

Status: Accepted Owner: ---- Labels: Type-CleanUp Priority-Low Version-Seaside2.9 New issue 266 by jfitzell: remove uses of generic Error http://code.google.com/p/seaside/issues/detail?id=266 We should be using more specific error subclasses. This means looking for senders of #error: and references to Error (many of these may be valid in #on:do: calls) in our code. At very least, it would be good to signal a WAError so that errors in Seaside code are distinguishable from others. This could be largely addressed by implementing #error: on WAObject but it would still be better to have more specific errors. This also implies that the few error classes we *do* have should be subclasses of WAError. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 161 in seaside: document error handling
by codesite-noreply＠google.com 29 Dec '08

29 Dec '08

Updates: Owner: jfitzell Comment #3 on issue 161 by jfitzell: document error handling http://code.google.com/p/seaside/issues/detail?id=161 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 161 in seaside: document error handling
by codesite-noreply＠google.com 29 Dec '08

29 Dec '08

Updates: Status: Started Comment #2 on issue 161 by jfitzell: document error handling http://code.google.com/p/seaside/issues/detail?id=161 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 264 in seaside: Help Button in "Seaside Control Panel"
by codesite-noreply＠google.com 29 Dec '08

29 Dec '08

Comment #2 on issue 264 by renggli: Help Button in "Seaside Control Panel" http://code.google.com/p/seaside/issues/detail?id=264 I've fixed the issue with the debugger. Still there control panel should display a propre message. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev December 2008