[Pharo-project] MIMEdatabase fix?
Hi can someone check http://code.google.com/p/pharo/issues/detail?id=520 Thanks
Filein it, then installing Seaside, (Installer universe install: 'Seaside(2.8.3.572)'.) => blank screen of depth 2009/2/24 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
can someone check http://code.google.com/p/pharo/issues/detail?id=520
Thanks _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Feb 24, 2009 at 3:29 PM, Hilaire Fernandes <hilaire@ofset.org> 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
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 <hilaire@ofset.org> 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 Pharo-project@lists.gforge.inria.fr 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
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
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
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
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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
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
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
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
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
So does contentType -> ^self somthing mimeType On 25-Feb-09, at 12:03 PM, Michael Rueger wrote:
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
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
OK, here we go... in the Pharo inbox there is a new version of Network-MIME and KomHTTPServer. The Kom package should also work on Squeak. Seaside would need to change its use of mimeType to contentType in a handful of places (my guess). Michael
Michael Rueger wrote:
OK, here we go... in the Pharo inbox there is a new version of Network-MIME and KomHTTPServer. The Kom package should also work on Squeak.
ok, one more thing ;-) Newer version of MIME package plus the attached change for Seaside makes at least the tests pass. Michael 'From Pharo0.1 of 16 May 2008 [Latest update: #10243] on 25 February 2009 at 1:09:34 pm'! !SeasidePlatformSupport class methodsFor: 'factory' stamp: 'michael.rueger 2/25/2009 13:05'! mimeDocumentOfType: type from: aFilename "WACachedDocument clearCache. (WACachedDocument fileName: 'SqueakDebug.log') asMIMEDocument. (WACachedDocument fileName: 'SqueakDebug.log') asMIMEDocument." | content mimeType | mimeType := type ifNil: [ self mimeDocumentClass guessContentTypeFromExtension: (FileDirectory extensionFor: aFilename) ]. content := (StandardFileStream readOnlyFileNamed: aFilename) contentsOfEntireFile. ^self mimeDocumentClass contentType: mimeType content: content! !
Michael Rueger wrote:
Michael Rueger wrote:
OK, here we go... in the Pharo inbox there is a new version of Network-MIME and KomHTTPServer. The Kom package should also work on Squeak.
ok, one more thing ;-) Newer version of MIME package plus the attached change for Seaside makes at least the tests pass.
-1 I don't have any interest at all to have a version of Seaside 2.8 for Squeak and one for Pharo. If you absolutely have to you can make some unholy, brittle hacks like we currently do for author initials to figure out if we're Squeak or Pharo. Maybe even an #isPharo method. Cheers Philippe
Philippe Marschall wrote:
Newer version of MIME package plus the attached change for Seaside makes at least the tests pass.
-1
I don't have any interest at all to have a version of Seaside 2.8 for Squeak and one for Pharo.
That's what I'm currently trying to avoid, but I need a little of your help on the Seaside side of things, at least a bit of testing. There is actually on more method (attached) that we need to add to either Kom or Seaside to make Pharo and Squeak compatible on the API level. Michael 'From Pharo0.1 of 16 May 2008 [Latest update: #10243] on 26 February 2009 at 10:50:21 am'! !MIMEDocument class methodsFor: 'compatibility' stamp: 'michael.rueger 2/25/2009 13:05'! guessContentTypeFromExtension: ext "guesses a content type from the extension" ^(self guessTypeFromExtension: ext) asString! !
Michael Rueger wrote:
Philippe Marschall wrote:
Newer version of MIME package plus the attached change for Seaside makes at least the tests pass.
-1
I don't have any interest at all to have a version of Seaside 2.8 for Squeak and one for Pharo.
That's what I'm currently trying to avoid,
It's better than monkey patching the system which is guaranteed to break again in the future.
but I need a little of your help on the Seaside side of things, at least a bit of testing.
Sure.
There is actually on more method (attached) that we need to add to either Kom or Seaside to make Pharo and Squeak compatible on the API level.
Sorry but no, see previous posts. Have a look at Seaside2.8a1-pmm.583 for what I would find acceptable. Cheers Philippe
Philippe Marschall wrote:
There is actually on more method (attached) that we need to add to either Kom or Seaside to make Pharo and Squeak compatible on the API level.
Sorry but no, see previous posts. Have a look at Seaside2.8a1-pmm.583 for what I would find acceptable.
OK, can you explain how I should make Seaside work on both Pharo and Squeak? I spent two days figuring out a minimal set of changes that would not require doing some ugly hack testing for which underlying platform you are dealing with and you say that is not acceptable? You *want* ugly hacks? I don't understand... I'm not even touching seaside (except the one method rename/addition for a method being called by Seaside). Michael
Michael Rueger wrote:
Philippe Marschall wrote:
There is actually on more method (attached) that we need to add to either Kom or Seaside to make Pharo and Squeak compatible on the API level. Sorry but no, see previous posts. Have a look at Seaside2.8a1-pmm.583 for what I would find acceptable.
OK, can you explain how I should make Seaside work on both Pharo and Squeak? I spent two days figuring out a minimal set of changes that would not require doing some ugly hack testing for which underlying platform you are dealing with and you say that is not acceptable? You *want* ugly hacks? I don't understand...
- Monkey patching either Seaside or Kom is not acceptable. We have this issue partially because Kom is monkey patching Squeak. - Forking Seaside for Pharo is not acceptable. - Relying on a forked Kom is not acceptable, we need to have a consistent interface for Kom in both Squeak an Pharo. That kinda limits our options. Second the fix is not that ugly. It just sends #asString to something it expects to be a String. This is not a that uncommon idiom. And we already have to do something way uglier for ensuring author initials. That's what happens if you break the API. You brake a lot of code and cause a lot of pain for a lot of people. Cheers Philippe
I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo. If you put too much constraints then do not cry after that squeak code is shitty because it is. On Feb 27, 2009, at 7:39 AM, Philippe Marschall wrote:
Michael Rueger wrote:
Philippe Marschall wrote:
There is actually on more method (attached) that we need to add to either Kom or Seaside to make Pharo and Squeak compatible on the API level. Sorry but no, see previous posts. Have a look at Seaside2.8a1-pmm. 583 for what I would find acceptable.
OK, can you explain how I should make Seaside work on both Pharo and Squeak? I spent two days figuring out a minimal set of changes that would not require doing some ugly hack testing for which underlying platform you are dealing with and you say that is not acceptable? You *want* ugly hacks? I don't understand...
- Monkey patching either Seaside or Kom is not acceptable. We have this issue partially because Kom is monkey patching Squeak. - Forking Seaside for Pharo is not acceptable. - Relying on a forked Kom is not acceptable, we need to have a consistent interface for Kom in both Squeak an Pharo.
That kinda limits our options.
Second the fix is not that ugly. It just sends #asString to something it expects to be a String. This is not a that uncommon idiom. And we already have to do something way uglier for ensuring author initials.
That's what happens if you break the API. You brake a lot of code and cause a lot of pain for a lot of people.
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Feb 27, 2009 at 10:30 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo.
The problem is that people load released versions from SqueakMap or Package Universe. As long as Pharo shares the Squeak Package Universe there is no way of cleanly deciding which version of Kom to load. In the long term (for upcoming version) we will have to decide what platform to support. I guess this will be Pharo 1.0 as soon as it has been released. It is too much trouble to keep the installers up-to-date and try to test and make them work on different versions and platforms. I suggest that people stick with Squeak 3.9.1 or early versions of Pharo for now. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Fri, Feb 27, 2009 at 12:02 PM, Lukas Renggli <renggli@gmail.com> wrote:
The problem is that people load released versions from SqueakMap or Package Universe. As long as Pharo shares the Squeak Package Universe there is no way of cleanly deciding which version of Kom to load.
Pharo will probably have its own copy of Universe. -- Damien Cassou http://damiencassou.seasidehosting.st
On Feb 27, 2009, at 12:02 PM, Lukas Renggli wrote:
On Fri, Feb 27, 2009 at 10:30 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo.
The problem is that people load released versions from SqueakMap or Package Universe. As long as Pharo shares the Squeak Package Universe there is no way of cleanly deciding which version of Kom to load.
ok now we can say that we have one Universe for Pharo so does it help solving the problem?
In the long term (for upcoming version) we will have to decide what platform to support. I guess this will be Pharo 1.0 as soon as it has been released. It is too much trouble to keep the installers up-to-date and try to test and make them work on different versions and platforms.
I imagine that pretty well.
I suggest that people stick with Squeak 3.9.1 or early versions of Pharo for now.
So may be we should tagged one version for alpha-pharo seasider and we take the decision that there will be a KOM for pharo and one for Squeak. Now I can integrate the changes of mike but I need a seaside creating the Pharo-KOM and testing that everything is ok.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo.
Loading is one thing. What bothers we more is the maintenance situation. Let's face it, there are far too resources behind something as important as Kom. Making a fork of it cuts these resources in half. Maintenance is not doing a quick fix now so that it loads. Maintenance is taking care of something for several years (!) to come, fixing issues as they arrive, being there and responding. Removing time from other activities instead of finding excuses. Cheers Philippe
Philippe Marschall wrote:
Stéphane Ducasse wrote:
I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo.
Loading is one thing. What bothers we more is the maintenance situation. Let's face it, there are far too resources behind something as important as Kom. Making a fork of it cuts these resources in half.
Hmm, I think most of the discussion is simply a misunderstanding, I'm not forking anything. With my changes to Pharo (which of course first need to be integrated), the changed (not forked!) version of Kom and the few changes for Seaside (which need to be integrated) there is no need for a fork!!! Those versions should work on both Squeak and Pharo. It's not monkey patching, none of the packages touch other stuff any more than they did before. I just changed Kom so its monkey patching now works on both Seaside and Pharo. And that's where I need you help testing. Michael
So you even got a solution :) Excellent! But this is also a good point because it means that for the future we will have again this kind of discussion.....exciting. Stef On Feb 27, 2009, at 6:06 PM, Michael Rueger wrote:
Philippe Marschall wrote:
Stéphane Ducasse wrote:
I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo.
Loading is one thing. What bothers we more is the maintenance situation. Let's face it, there are far too resources behind something as important as Kom. Making a fork of it cuts these resources in half.
Hmm, I think most of the discussion is simply a misunderstanding, I'm not forking anything.
With my changes to Pharo (which of course first need to be integrated), the changed (not forked!) version of Kom and the few changes for Seaside (which need to be integrated) there is no need for a fork!!!
Those versions should work on both Squeak and Pharo.
It's not monkey patching, none of the packages touch other stuff any more than they did before. I just changed Kom so its monkey patching now works on both Seaside and Pharo.
And that's where I need you help testing.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
With my changes to Pharo (which of course first need to be integrated),
I will integrate them this evening.
the changed (not forked!) version of Kom and the few changes for Seaside (which need to be integrated) there is no need for a fork!!!
Those versions should work on both Squeak and Pharo.
It's not monkey patching, none of the packages touch other stuff any more than they did before. I just changed Kom so its monkey patching now works on both Seaside and Pharo.
And that's where I need you help testing.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
With my changes to Pharo (which of course first need to be integrated),
I will integrate them this evening.
A quick test with loading the following packages into both the latest Pharo and a Squeak 3.9.1 image seemed to work :-) from http://www.squeaksource.com/KomHttpServer DynamicBindings-gc.7 NamedProcess-RJT.2 KomServices-gc.19 from http://squeaksource.com/PharoInbox KomHttpServer-michael_rueger.45 from http://squeaksource.com/Seaside Seaside2.8a1-pmm.583 Michael
excellent! I'm happy.
With my changes to Pharo (which of course first need to be integrated),
I will integrate them this evening.
A quick test with loading the following packages into both the latest Pharo and a Squeak 3.9.1 image seemed to work :-)
from http://www.squeaksource.com/KomHttpServer DynamicBindings-gc.7 NamedProcess-RJT.2 KomServices-gc.19
from http://squeaksource.com/PharoInbox KomHttpServer-michael_rueger.45
from http://squeaksource.com/Seaside Seaside2.8a1-pmm.583
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Michael Rueger wrote:
Philippe Marschall wrote:
Stéphane Ducasse wrote:
I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo. Loading is one thing. What bothers we more is the maintenance situation. Let's face it, there are far too resources behind something as important as Kom. Making a fork of it cuts these resources in half.
Hmm, I think most of the discussion is simply a misunderstanding, I'm not forking anything.
With my changes to Pharo (which of course first need to be integrated), the changed (not forked!) version of Kom and the few changes for Seaside (which need to be integrated) there is no need for a fork!!!
Those versions should work on both Squeak and Pharo.
Very well then. Can you contact Giovanni to have your changes integrated at: http://www.squeaksource.com/KomHttpServer.html
It's not monkey patching, none of the packages touch other stuff any more than they did before. I just changed Kom so its monkey patching now works on both Seaside and Pharo.
And that's where I need you help testing.
I did a short test with Seaside 2.8 and Squeak 3.9 and it seems to work. Cheers Philippe
Those versions should work on both Squeak and Pharo.
Cool Excellent
Very well then. Can you contact Giovanni to have your changes integrated at:
Giovanni we need your help so get the changes that are in the PharoInbox repository on squeaksource in KomHttpServer. Can you help us?
It's not monkey patching, none of the packages touch other stuff any more than they did before. I just changed Kom so its monkey patching now works on both Seaside and Pharo.
And that's where I need you help testing.
I did a short test with Seaside 2.8 and Squeak 3.9 and it seems to work.
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse ha scritto:
Those versions should work on both Squeak and Pharo.
Cool Excellent
Very well then. Can you contact Giovanni to have your changes integrated at:
Giovanni we need your help so get the changes that are in the PharoInbox repository on squeaksource in KomHttpServer.
Can you help us?
Hi Stef, I gave a look at Micheal fix, and have integrated it into KomHttpServer-gc.45.mcz available in the main KomHttpServer repository ( http://www.squeaksource.com/KomHttpServer/ ). Still need to be tested though. Giovanni
Giovanni Corriga wrote:
I gave a look at Micheal fix, and have integrated it into KomHttpServer-gc.45.mcz available in the main KomHttpServer repository ( http://www.squeaksource.com/KomHttpServer/ ). Still need to be tested though.
Thank you! :-) Michael
you know I guess that I know what is maintenance.
I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo.
Loading is one thing. What bothers we more is the maintenance situation. Let's face it, there are far too resources behind something as important as Kom. Making a fork of it cuts these resources in half.
Maintenance is not doing a quick fix now so that it loads. Maintenance is taking care of something for several years (!) to come, fixing issues as they arrive, being there and responding. Removing time from other activities instead of finding excuses.
So what is your suggestion then because so far the only message we got is that we should not change network because KOM is crappy. So ****concretely**** what can we do. So far you have not been that constructive. If we do not have paths for the future then why Seasiders even think about using Pharo. May be you should get stuck in Squeak and this is ok too. Stef
Philippe, One idea: Kom needs MIME support, Swazoo does not. So in case of Swazoo you deal with a MIME in web server adapter, right? What if you do the same, use your own MIME support in adapter for Kom as well? Best regards Janko Philippe Marschall pravi:
Stéphane Ducasse wrote:
I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo.
Loading is one thing. What bothers we more is the maintenance situation. Let's face it, there are far too resources behind something as important as Kom. Making a fork of it cuts these resources in half.
Maintenance is not doing a quick fix now so that it loads. Maintenance is taking care of something for several years (!) to come, fixing issues as they arrive, being there and responding. Removing time from other activities instead of finding excuses.
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
Second the fix is not that ugly. It just sends #asString to something it expects to be a String. This is not a that uncommon idiom. And we already have to do something way uglier for ensuring author initials.
How about taking the Author initials stuff from pharo, and publishing it as a package that will load into squeak. Then coding seaside to the new api. This is something I plan to do for squeak anyway at some point, but if you have a need for it now. Also if you have any pressing fixes that squeak needs we can put that fix into lpf for all images 3.7+ Keith
Hi philppe If seaside people does not help then you should not complain that Squeak sucks and that nothing is fixed. So what is important it to find what is reasonable to do. So either help and we will arrive to a fix point or don't complain for the next 5 years. Stef
Michael Rueger wrote:
Michael Rueger wrote:
OK, here we go... in the Pharo inbox there is a new version of Network-MIME and KomHTTPServer. The Kom package should also work on Squeak.
ok, one more thing ;-) Newer version of MIME package plus the attached change for Seaside makes at least the tests pass.
-1
I don't have any interest at all to have a version of Seaside 2.8 for Squeak and one for Pharo.
If you absolutely have to you can make some unholy, brittle hacks like we currently do for author initials to figure out if we're Squeak or Pharo. Maybe even an #isPharo method.
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok I will try to get some time to integrate that this evening. Thanks mike. Stef On Feb 25, 2009, at 9:53 PM, Michael Rueger wrote:
OK, here we go... in the Pharo inbox there is a new version of Network-MIME and KomHTTPServer. The Kom package should also work on Squeak.
Seaside would need to change its use of mimeType to contentType in a handful of places (my guess).
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Feb 25, 2009, at 5:59 PM, 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.
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.
No else we would not have done pharo. The point is more how can we help people migrating to pharo. Probably having a specific Kom version. Stef
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
On Feb 25, 2009, at 5:59 PM, 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. 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.
No else we would not have done pharo. The point is more how can we help people migrating to pharo. Probably having a specific Kom version.
You help people if you have a maintained version of Kom (see other mail). If you don't have a maintained web server then you are hurting people. Simply making a fork of Kom is not maintenance, on the contrary. Philippe
participants (10)
-
Damien Cassou -
Giovanni Corriga -
Hilaire Fernandes -
Janko Mivšek -
John M McIntosh -
Keith Hodges -
Lukas Renggli -
Michael Rueger -
Philippe Marschall -
Stéphane Ducasse