HTTPSocket latest
Locked
 
|
Hi,
I'm attempting to update to the latest versions of HTTPSocket class>>#httpPostDocument:args:accept:request: - to see if the latest versions fix an incompatibility between the Pharo and Gemstone implementations I've hit.
I've updated my local GLASS version to 1.0-beta.8.6, and noticed that in the repository: http://seaside.gemstone.com/ss/monticello, package: 'Squeak' that Otto had made some recent(ish) fixes to #httpPostDocument:args:accept:request:. The good news is that these appear to solve my problem. However the latest changes seem to rely on changes to Sport - namely SpSocket & SpSocketAddress. I'm struggling to find the repository which holds these updates. Can anyone point me at the repository. Naive question - Is there a way of determining the package and repository holding a specific class in Gemstone?
Thanks Nick |
|
Am 31.03.2011 um 14:53 schrieb Nick Ager: > Can anyone point me at the repository. Naive question - Is there a way of determining the package and repository holding a specific class in Gemstone? Sure. A class is contained in a category. A category matches a monticello package. And a monticello package has an repository (or more) attached. So find the class via the class browser you will see the category on the left. Opening monticello and looking for the name will show you the repo. Norbert |
|
|
Am 31.03.2011 um 15:01 schrieb Norbert Hartl: > > Am 31.03.2011 um 14:53 schrieb Nick Ager: > >> Can anyone point me at the repository. Naive question - Is there a way of determining the package and repository holding a specific class in Gemstone? > > Sure. A class is contained in a category. A category matches a monticello package. And a monticello package has an repository (or more) attached. So find the class via the class browser you will see the category on the left. Opening monticello and looking for the name will show you the repo. Btw, it is http://seaside.gemstone.com/ss/hyper ;) Norbert |
|
|
Sure - can someone point me at some code that will go from a category to a package and repository or have I missed a trick on GemTools UI?
I don't see changes in package "Sport3.010" that match the changes to the latest version of HTTPSocket. Are the Sport changes in a different package?
|
|
|
In reply to this post by Nick
Nick,
I had intended to integrate Otto's changes into 1.0-beta.8.6, but ran into the missing classes (and sent mail to this list asking the same question as you:): I started to integrate Squeak-OttoBehrens.260 (where Otto's changes are saved) and discovered that it uses SpIPAddress>>ipAddressForHostName:timeout: which isn't implemented ... presumably it should be included in the Sport3.010 package?... I didn't notice the problems with SpSocket and SpSocketAddress, because I stopped looking once I noticed that SpIpAddress was missing... So Otto, could you help with the SpIPAddress that you are using? Thanks, Dale On Mar 31, 2011, at 5:53 AM, Nick Ager wrote: Hi, I'm attempting to update to the latest versions of HTTPSocket class>>#httpPostDocument:args:accept:request: - to see if the latest versions fix an incompatibility between the Pharo and Gemstone implementations I've hit. I've updated my local GLASS version to 1.0-beta.8.6, and noticed that in the repository: http://seaside.gemstone.com/ss/monticello, package: 'Squeak' that Otto had made some recent(ish) fixes to #httpPostDocument:args:accept:request:. The good news is that these appear to solve my problem. However the latest changes seem to rely on changes to Sport - namely SpSocket & SpSocketAddress. I'm struggling to find the repository which holds these updates. Can anyone point me at the repository. Naive question - Is there a way of determining the package and repository holding a specific class in Gemstone? Thanks Nick |
|
|
Sorry again, I am missed this mail and discovered it today. I did
attach the packages in an email on this thread; I just checked and it contains the implementation of SpIPAddress>>ipAddressForHostName:timeout: I am more than willing to fix and publish. Please help me out: I am uncertain where to publish and what to change / not. I tried to find where to publish Sport3.010 (why that name?). I see that there is a quite old release http://squeaksource.com/SPort/. Why not just update there and make sure all the configs know where it is? > I had intended to integrate Otto's changes into 1.0-beta.8.6, but ran into the missing classes (and sent mail to this list asking the same question as you:): > > I started to integrate Squeak-OttoBehrens.260 (where Otto's changes are saved) and discovered > that it uses SpIPAddress>>ipAddressForHostName:timeout: which isn't implemented ... presumably > it should be included in the Sport3.010 package?... > > I didn't notice the problems with SpSocket and SpSocketAddress, because I stopped looking once I noticed that SpIpAddress was missing... > > So Otto, could you help with the SpIPAddress that you are using? > > Thanks, > > Dale > > On Mar 31, 2011, at 5:53 AM, Nick Ager wrote: > > Hi, > > I'm attempting to update to the latest versions of HTTPSocket class>>#httpPostDocument:args:accept:request: - to see if the latest versions fix an incompatibility between the Pharo and Gemstone implementations I've hit. > I've updated my local GLASS version to 1.0-beta.8.6, and noticed that in the repository: http://seaside.gemstone.com/ss/monticello, package: 'Squeak' that Otto had made some recent(ish) fixes to #httpPostDocument:args:accept:request:. The good news is that these appear to solve my problem. However the latest changes seem to rely on changes to Sport - namely SpSocket & SpSocketAddress. I'm struggling to find the repository which holds these updates. Can anyone point me at the repository. Naive question - Is there a way of determining the package and repository holding a specific class in Gemstone? > > Thanks > > Nick > > > > > |
|
|
On 04/05/2011 10:46 AM, Otto Behrens wrote:
> Sorry again, I am missed this mail and discovered it today. I did > attach the packages in an email on this thread; I just checked and it > contains the implementation of > SpIPAddress>>ipAddressForHostName:timeout: Ah, I had missed the attachment and was going by the checked in mcz files ... > > I am more than willing to fix and publish. Please help me out: I am > uncertain where to publish and what to change / not. I tried to find > where to publish Sport3.010 (why that name?). I see that there is a > quite old release http://squeaksource.com/SPort/. Why not just update > there and make sure all the configs know where it is? The sport packages are hidden in the Hyper repository: http://seaside.gemstone.com/ss/hyper.html The Sport stuff was initially based on the Sport code that Bruce maintained in Store via VisualWorks and at the time was the latest and greatest version for GemStone ... The name Sport3.010 corresponds to the version number of Sport in Store that was ported to GemStone. The Sport package for GLASS is managed in the GsCore configuration, since it is required as part of the base GLASS implementation. So at the moment, if you have a new version of Sport3.010, copying that version to the Hyper repository followed by email, will be enough for me to incorporate it into the next release of GLASS ... > >> I had intended to integrate Otto's changes into 1.0-beta.8.6, but ran into the missing classes (and sent mail to this list asking the same question as you:): >> >> I started to integrate Squeak-OttoBehrens.260 (where Otto's changes are saved) and discovered >> that it uses SpIPAddress>>ipAddressForHostName:timeout: which isn't implemented ... presumably >> it should be included in the Sport3.010 package?... >> >> I didn't notice the problems with SpSocket and SpSocketAddress, because I stopped looking once I noticed that SpIpAddress was missing... >> >> So Otto, could you help with the SpIPAddress that you are using? >> >> Thanks, >> >> Dale >> >> On Mar 31, 2011, at 5:53 AM, Nick Ager wrote: >> >> Hi, >> >> I'm attempting to update to the latest versions of HTTPSocket class>>#httpPostDocument:args:accept:request: - to see if the latest versions fix an incompatibility between the Pharo and Gemstone implementations I've hit. >> I've updated my local GLASS version to 1.0-beta.8.6, and noticed that in the repository: http://seaside.gemstone.com/ss/monticello, package: 'Squeak' that Otto had made some recent(ish) fixes to #httpPostDocument:args:accept:request:. The good news is that these appear to solve my problem. However the latest changes seem to rely on changes to Sport - namely SpSocket& SpSocketAddress. I'm struggling to find the repository which holds these updates. Can anyone point me at the repository. Naive question - Is there a way of determining the package and repository holding a specific class in Gemstone? >> >> Thanks >> >> Nick >> >> >> >> >> |
|
|
I was bitten again by incompatibilities between Pharo and Gemstones HTTPSocket httpPost and httpGet so hopefully better late than never, I've copied and merged Otto's Sport changes into http://seaside.gemstone.com/ss/hyper/Sport3.010 - see Sport3.010-NickAger.24 and I've merged a set of changes which appeared to be orphaned by Otto's changes to HTTPSocket httpPost and httpGet in http://seaside.gemstone.com/ss/monticello/Squeak. There still seems to be an orphaned change from Norbert - Squeak-NorbertHartl.242.
Hopefully the merging makes sense - there also appeared to be a lot of orphaned changes to the Sport package but I'm guessing that as the orphans and latest code was all Dale's this is intentional.
IIRC Pharo 1.3 is dropping HTTPSocket implementation is favour of the Zinc components so I guess at some stage the GLASS implementation can swap out HTTPSocket for Zinc as well.
Nick On 7 April 2011 18:05, Dale Henrichs <[hidden email]> wrote:
|
|
|
Am 01.06.2011 um 15:32 schrieb Nick Ager: > IIRC Pharo 1.3 is dropping HTTPSocket implementation is favour of the Zinc components so I guess at some stage the GLASS implementation can swap out HTTPSocket for Zinc as well. I hope this will be the case. But first we need to make the zinc port more clear. I had troubles loading the right versions. Paul wanted to have a look after that. If I understood Dale right than a lot of the overrides in the zinc packages have been merged into pharo compat. So one step would be to remove those overrides from the zinc package. Finally there are 8 tests failing that we should fix. Norbert |
|
|
I intend to revisit the Zinc port this afternoon/tomorrow AM and hope
to bring it in line with the latest version from SqueakSource. I have not looked at it since mid April and know that Dale has made changes to GLASS and Sven has fixed some serious Zinc bugs since then. Some of the failing tests are due to some stream based classes (gzip and JPEG) that don't exist in Gemstone. I don't expect to do anything about those until the Gemstone 3.0 general release as it contains revisions to the Stream classes that I guess will make porting much simpler. If anyone wants to port those before then please do. I'd appreciate any suggestions or revisions about the port from anyone who's interested in making them. Norbert - your Jenkins server still loads the Zinc code without error. What version of GLASS is it running? Thanks Paul On Wed, Jun 1, 2011 at 9:46 AM, Norbert Hartl <[hidden email]> wrote: > > Am 01.06.2011 um 15:32 schrieb Nick Ager: > >> IIRC Pharo 1.3 is dropping HTTPSocket implementation is favour of the Zinc components so I guess at some stage the GLASS implementation can swap out HTTPSocket for Zinc as well. > > > I hope this will be the case. But first we need to make the zinc port more clear. I had troubles loading the right versions. Paul wanted to have a look after that. If I understood Dale right than a lot of the overrides in the zinc packages have been merged into pharo compat. So one step would be to remove those overrides from the zinc package. Finally there are 8 tests failing that we should fix. > > Norbert |
|
|
Am 01.06.2011 um 17:12 schrieb Paul DeBruicker: > Norbert - your Jenkins server still loads the Zinc code without error. > What version of GLASS is it running? It is 2.4.4.1. I can load the code as well but I encountered a few problems. In my case using the ConfigurationOf it loaded the code from gemsource repository. And after having loaded the code there were already plenty of changes in the package when looking at monticello. That's what I meant about the overrides in the packages. I don't know if I loaded the right packages. And if so they didn't load in a clean way. Norbert |
|
|
In reply to this post by Nick
Hi,
An update on my Sport and HTTPSocket merging:
On 1 June 2011 14:32, Nick Ager <[hidden email]> wrote: I was bitten again by incompatibilities between Pharo and Gemstones HTTPSocket httpPost and httpGet so hopefully better late than never, I've copied and merged Otto's Sport changes into http://seaside.gemstone.com/ss/hyper/Sport3.010 - see Sport3.010-NickAger.24 and I've merged a set of changes which appeared to be orphaned by Otto's changes to HTTPSocket httpPost and httpGet in http://seaside.gemstone.com/ss/monticello/Squeak. There still seems to be an orphaned change from Norbert - Squeak-NorbertHartl.242. I found that the integration in Squeak-NickAger.262 somehow causes the FastCGI server to stop functioning. I've tried debugging with breakpoints in #internalServerMalfunction: and #internalServerErrorMessage: but to no avail.
My front end server (Nginx) reports: FastCGI sent in stderr: "InterpreterError 2192: End of stream was encountered in ReadStream: <anAnsiReadStream>" while reading response header from upstream, client: 172.16.181.1, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "172.16.181.203"
followed by: upstream prematurely closed connection while reading response header from upstream, client: 172.16.181.1, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "172.16.181.203"
Working back along the integrations it appears the problem is with the code brought in by Squeak-dkh.258 The check-in details for Squeak-dkh.258 are:
Name: Squeak-dkh.258 Author: dkh Time: 25 March 2011, 14:02:05 UUID: 99c21aef-2115-425f-82a9-98f7ead16e24 Ancestors: Squeak-dkh.257 - fix Issue 229: ScaledDecimal class>>readFrom: returns Number not ScaledDecimal
- fix Issue 230: Number class>>readFrom: fails when Locale class>>decimalPoint not '.'
In the meantime I've rolled back Squeak-dkh.258 with a new integration Squeak-NickAger.263, which includes all previous work without Squeak-dkh.258.
I've probably missed something simple - but without being able to simply debug and running out of time I'm left unable to fix the problems when integrating Squeak-dkh.257
Nick |
|
|
I've created issue 273:
http://code.google.com/p/glassdb/issues/detail?id=273
On 6 June 2011 14:04, Nick Ager <[hidden email]> wrote: Hi, |
|
|
I've created issue 273:
|
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |