Dear all,
Smallwiki's RSS feed does, at least for Vienna, not report all
changes. Since the name of an RSS feed entry acts as unique key,
changes on a page are only reported once and then never ever again.
Is this a Vienna only problem, or general?
cheers,
AA
Thanks, but I force this class to work properly before sending this
message.
"My class don't work" is not a trouble now, trouble is "something wrong
with some of squeaks details".
I try recompiling, it works.
So, as far as I understand, it will be good to locate the action
generates this bug.
Help!
Hi All,
A while ago Lukas gave me the following code for opening a pier widget
so that it would be able to access its context even though we are not
even in a pier application!
self - is my control panel which runs in the WADispatcherEditor's session.
widget is PUUsers or PUGroups
ControlPanel-callWidget: widget titled: title
PRCurrentContext use: self during: [
WARenderLoop new call: (widget
addDecoration: (WAWindowDecoration new
title: title;
yourself);
yourself) ]
This works to the extent that the widget displays correctly, however the
buttons do not work due to PRCurrentContext value being nil.
I am using the latest everything in the development universes.
Does anyone have any ideas?
thanks in advance
Keith
I locate some strange bug when I working for Seaside on Sails.
How to look at it:
1) load http://richart-consalt.ru/Sails.bugged.zip, unpack it (all
needed including VM inside)
2) run it
3) in left top corner you'll see workspace with strings
SailsTest test2.
blg:=BlogPost new.
blg title:'1111'.
blg title
blg comments
4) say "do it" to strings
blg:=BlogPost new.
blg title:'1111'.
5) and then say "print it" to strings
blg title
blg comments
It prints '1111' both for comments and title accessors.
But BlogPost is quite simple object: Object child with 3 instvars:
title, post, comments. comments:=OrderedCollection new in initialize.
Accessors (automatically made) for all 3 instvars. Nothing more.
So "blg comments" must return emty ordered collection, not a title string...
Some more comments:
a) Sometimes both title and comments accessors returns empty ordered
collection
b) If you inspect blg, you will see strange instvars values sometimes
and sometimes - normal values (but accessos still return buggy values)
c) Bug disappear as fast as I locate it and put breakpoints to accessor
to catch it.
d) Bug can interact not only with workspace, as far as it disappeare my
Seaside example become functional (it failed before, becouse #add: was
applied to title string returned by comments accessor).
==============
Assargadon
tallman(a)inbox.ru
http://headache.h1.ru
> Date: Sun, 22 Jul 2007 22:42:14 +0200> From: philippe.marschall(a)gmail.com> To: smallwiki(a)iam.unibe.ch> Subject: Re: Differences w/ exception handling in Magritte..?>> Then use streams. See senders of #braceStream:I suppose that's doable. I know how to do it, but it's not as concise as the curly-array syntax.> No. Just don't use curly brace arrays.> > PhilippeIt's not the braces I care about, it's the concise way of constructing an array from values that are evaluated at runtime instead of compile time.
_________________________________________________________________
Missed the show? Watch videos of the Live Earth Concert on MSN.
http://liveearth.msn.com
I was afraid you would say that. :( Is it limited to 4 with:'s like Squeak? In any case, VW does allow one to add behaviors to # easier last I heard. Maybe I can just make a #{} as part of my package. :)> Date: Sun, 22 Jul 2007 13:16:32 +0200> From: philippe.marschall(a)gmail.com> To: smallwiki(a)iam.unibe.ch> Subject: Re: Differences w/ exception handling in Magritte..?> > 2007/7/22, J J <azreal1977(a)hotmail.com>:> >> >> >> > ________________________________> > Date: Thu, 12 Jul 2007 14:42:34 -0400> > From: koschate(a)omasko.com> > To: renggli(a)iam.unibe.ch> > Subject: Re: Differences w/ exception handling in Magritte..?> > CC: renggli(a)gmail.com; smallwiki(a)iam.unibe.ch> >> >> > While I remember, a request to help with future ports: Please avoid the use> > of {} to define arrays, as VisualWorks doesn't know how to deal with this.> > --> > ============================================================> > Thomas Koschate> >> >> >> > Hrm, I use this a bit in my recurrence rules code. How do you get the same> > functionality in VW?> > Array with: with:...> > Philippe> > _______________________________________________> SmallWiki, Magritte, Pier and Related Tools ...> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_________________________________________________________________
See what you’re getting into…before you go there.
http://newlivehotmail.com
Hi,
I've currently no time to keep track of magritte, pier and seaside on
the Universe. It's a very simple task, but it requires to be informed
about what version of pier blog works with which version of RSRSS,
magritte and seaside...
The universe is interesting to help people install whatever they want easily.
Does anyone wants to help me?
--
Damien Cassou
Date: Thu, 12 Jul 2007 14:42:34 -0400From: koschate(a)omasko.comTo: renggli(a)iam.unibe.chSubject: Re: Differences w/ exception handling in Magritte..?CC: renggli(a)gmail.com; smallwiki(a)iam.unibe.chWhile I remember, a request to help with future ports: Please avoid the use of {} to define arrays, as VisualWorks doesn't know how to deal with this.-- ============================================================
Thomas KoschateHrm, I use this a bit in my recurrence rules code. How do you get the same functionality in VW?
_________________________________________________________________
Missed the show? Watch videos of the Live Earth Concert on MSN.
http://liveearth.msn.com
Hi,
in my image, PRPierMain>>invalidDispatcher: causes an improper store
into indexable object
WAResponse internalError: 'bla bla'
executing the last line causes the error...in
SeasideSupportPlatform>>walkbackStringFor:
is it because error are not meant to be a string (anymore) ? ... don't
know how to fix...
I use the last seaside and pier version.
Cédrick
I'm doing the following:
renderContentOn: html
html render: ((self parent person asComponent)
readonly: true;
yourself ).
html form with: [html submitButton callback: [self editClient];
value: 'edit']
To view a model object... everything seems to work fine. When I
toggle halos and try to see source or inspect one of the Magritte
components, it fails, because they aren't being returned by #children
anywhere. Is there a way I can cache the component, or do this a
different way?
Thanks,
Brian
