Hi
can someone check http://code.google.com/p/pharo/issues/detail?id=520 Thanks _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project MimeDB39Extensions.1.cs (4K) Download Attachment |
Filein it, then installing Seaside,
(Installer universe install: 'Seaside(2.8.3.572)'.) => blank screen of depth 2009/2/24 Stéphane Ducasse <[hidden email]>: > Hi > > can someone check > http://code.google.com/p/pharo/issues/detail?id=520 > > > > > > > Thanks > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://blog.ofset.org/hilaire _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Tue, Feb 24, 2009 at 3:29 PM, Hilaire Fernandes <[hidden email]> wrote:
> Filein it, then installing Seaside, > (Installer universe install: 'Seaside(2.8.3.572)'.) > > => blank screen of depth I confirm. This is because of infinite recursion: MIMEDocument>>type calls #contentType which calls #mimetype which calls #type which calls... I think that #mimetype should directly returns the instance variable 'type' -- Damien Cassou http://damiencassou.seasidehosting.st _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Ok I will have a look.
I was probably silly On Feb 24, 2009, at 4:31 PM, Damien Cassou wrote: > On Tue, Feb 24, 2009 at 3:29 PM, Hilaire Fernandes > <[hidden email]> wrote: >> Filein it, then installing Seaside, >> (Installer universe install: 'Seaside(2.8.3.572)'.) >> >> => blank screen of depth > > I confirm. This is because of infinite recursion: > > MIMEDocument>>type calls #contentType which calls #mimetype which > calls #type which calls... > > I think that #mimetype should directly returns the instance variable > 'type' > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Stéphane Ducasse wrote:
> Ok I will have a look. > I was probably silly I'll have a look. Apologies, got distracted by the unicode stuff... Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Michael Rueger wrote:
> Stéphane Ducasse wrote: >> Ok I will have a look. >> I was probably silly Well, basically the Kom package is in the old Squeak tradition of mangling the system until it seems fit. The number and kind of extensions all over the system make it more or less incompatible with the MIME (and other) changes in the current Pharo image. This is a situation we will increasingly encounter when we start to really deliver on the promise of cleaning up the system: packages will become incompatible to an extent that we can't -and shouldn't or rather must not- patch around. Polymorph is the next candidate regarding the unicode changes as it touches the same areas of the system. Comments? Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Feb 24, 2009, at 7:26 PM, Michael Rueger wrote: > Michael Rueger wrote: >> Stéphane Ducasse wrote: >>> Ok I will have a look. >>> I was probably silly > > Well, basically the Kom package is in the old Squeak tradition of > mangling the system until it seems fit. The number and kind of > extensions all over the system make it more or less incompatible with > the MIME (and other) changes in the current Pharo image. > > > This is a situation we will increasingly encounter when we start to > really deliver on the promise of cleaning up the system: packages will > become incompatible to an extent that we can't -and shouldn't or > rather > must not- patch around. Probably now for resetMIMEdatabase it was not an extension of anypackage in Squeak 3.9. So can you fix that or there is something I do not understand. Then I think that we should first make sure that seaside can run and after we should really put pression on the KOM maintainer or declare that it is incompatible with pharo and hope that > Polymorph is the next candidate regarding the unicode changes as it > touches the same areas of the system. > > Comments? We discussed the overriding policy of Polymorph with adrian lukas and marcus and normally if I remember well we should contact gary to get a much better integration. We really think that this is important to not have override in Pharo. May be gary will read this one else we should launch a new thread. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> Then I think that we should first make sure that seaside can run and
> after we should > really put pression on the KOM maintainer or declare that it is > incompatible with pharo > and hope that Philippe reported to Giovanni that Kom does not work in Pharo. He replied that he has no time to work on it at the moment. I hope that somebody will jump in, because Kom is a central part of Seaside and widely adapted for many productive applications. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Lukas Renggli wrote:
>> Then I think that we should first make sure that seaside can run and >> after we should >> really put pression on the KOM maintainer or declare that it is >> incompatible with pharo >> and hope that > > Philippe reported to Giovanni that Kom does not work in Pharo. He > replied that he has no time to work on it at the moment. I hope that > somebody will jump in, because Kom is a central part of Seaside and > widely adapted for many productive applications. If everybody is ok with that we could start a forked version and make it work on Pharo. I would volunteer to at least try to fix the problems. Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi all,
there is a hopefully fixed version of the Kom package in the Pharo inbox. I'm not familiar with Universes yet, so I can't easily make a modified loader for Seaside or Pier. There is an error in the Kom package comment, the method mimeType does not get removed if you load the Kom package into a fresh image. It will get removed if you update the Kom package (IIRC the way Monticello handles these things). Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Michael Rueger-6
what seasiders think?
I would be in favor to get a KOM pharo version Stef On Feb 24, 2009, at 11:47 PM, Michael Rueger wrote: > Lukas Renggli wrote: >>> Then I think that we should first make sure that seaside can run and >>> after we should >>> really put pression on the KOM maintainer or declare that it is >>> incompatible with pharo >>> and hope that >> >> Philippe reported to Giovanni that Kom does not work in Pharo. He >> replied that he has no time to work on it at the moment. I hope that >> somebody will jump in, because Kom is a central part of Seaside and >> widely adapted for many productive applications. > > If everybody is ok with that we could start a forked version and > make it > work on Pharo. I would volunteer to at least try to fix the problems. > > Michael > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Michael Rueger-6
> there is a hopefully fixed version of the Kom package in the Pharo inbox.
> I'm not familiar with Universes yet, so I can't easily make a modified > loader for Seaside or Pier. Is it backward compatible? Do your changes to Kom continue to work in Squeak 3.9? If so, we should probably publish it to the official Kom repository: <http://www.squeaksource.com/KomWebServer>. After some testing, I can do a new Seaside and Pier release. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stéphane Ducasse
> what seasiders think?
> I would be in favor to get a KOM pharo version Having two incompatible versions of Kom makes distribution even more painful as it is today. I would prefer to have compatible versions if this is possible. Otherwise Seaside won't run on Squeak anymore, unless somebody steps up and does all the testing, porting and integration work. We don't have the capacity to maintain different distribution paths and ports. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Lukas Renggli wrote:
>> what seasiders think? >> I would be in favor to get a KOM pharo version > > Having two incompatible versions of Kom makes distribution even more > painful as it is today. I would prefer to have compatible versions if > this is possible. As I said, we are at or at least close to the point where we have to make the decision which version to support. If you want to have Pharo stay compatible with Squeak, we can just as well abandon Pharo now. It's as simple as that. Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Michael Rueger wrote:
> Lukas Renggli wrote: >>> what seasiders think? >>> I would be in favor to get a KOM pharo version >> Having two incompatible versions of Kom makes distribution even more >> painful as it is today. I would prefer to have compatible versions if >> this is possible. I will see that I can get Pharo, Kom and Squeak compatible enough for now, no point in riding this out on principle. Nevertheless the issue still stands, that at some point we have to make that decision. Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Michael Rueger-6
>> Having two incompatible versions of Kom makes distribution even more
>> painful as it is today. I would prefer to have compatible versions if >> this is possible. > > As I said, we are at or at least close to the point where we have to > make the decision which version to support. If you want to have Pharo > stay compatible with Squeak, we can just as well abandon Pharo now. > It's as simple as that. I am not criticizing your effort to make Kom work on Pharo. I fully agree with you that Pharo should move forward and if necessary break backward compatibility. My question was only if this was the case with the changes on Kom. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Michael Rueger-6
Ok, well it seems to me having KOM and pharo working is *very*
important, actually I'm relying on that for a meeting I'm having on friday. Obviously I'll use a version of Pharo from last month... Going forward you can burn all those bridges, but I'm not sure people supporting that other non-pharo stuff would care. Could you have a shim layer that is loaded to respect KOM's expectations for behaviour? Well or otherwise built a completely new MIME system for Pharo and let KOM continue with the obsolete one? On 25-Feb-09, at 10:13 AM, Michael Rueger wrote: > Michael Rueger wrote: >> Lukas Renggli wrote: >>>> what seasiders think? >>>> I would be in favor to get a KOM pharo version >>> Having two incompatible versions of Kom makes distribution even more >>> painful as it is today. I would prefer to have compatible versions >>> if >>> this is possible. > > I will see that I can get Pharo, Kom and Squeak compatible enough for > now, no point in riding this out on principle. > > Nevertheless the issue still stands, that at some point we have to > make > that decision. > > Michael > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Lukas Renggli
Lukas Renggli wrote:
> I am not criticizing your effort to make Kom work on Pharo. I fully > agree with you that Pharo should move forward and if necessary break > backward compatibility. My question was only if this was the case with > the changes on Kom. Not in the current version. I'm looking at it again, had some ideas this morning how to make it work for now. Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by johnmci
John M McIntosh wrote:
> Ok, well it seems to me having KOM and pharo working is *very* > important, actually > I'm relying on that for a meeting I'm having on friday. Obviously I'll > use a version of > Pharo from last month... > > Going forward you can burn all those bridges, but I'm not sure people > supporting that > other non-pharo stuff would care. > > Could you have a shim layer that is loaded to respect KOM's > expectations for behaviour? > Well or otherwise built a completely new MIME system for Pharo and let > KOM continue > with the obsolete one? The changes are actually not many, but at a few critical points they matter and Kom is very aggressive in overriding stuff. That makes it hard coming up with an intermediate layer. But working on it :-) Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Michael Rueger-6
Hi all,
ok, suggestion: if we change Kom and Seaside to use the message contentType where they expect a mime type string, then it would be easy to make it work on both Pharo and Squeak without too much trouble. Seaside doesn't call mimeType on many places and usage is somewhat inconsistent right now as in httpResponse contentType = aHandler mimeType Comments? Suggestions? Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |