[Glass] [3.1.0.4] Set>>deepCopy

In 3.1.0.4:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi!

I have some trouble usinf ZINC on Gemstone 3.1.0.4

Here is my Zinc script.
If I execute these two lines. My server doe not respond on:
http://myserverIP:8080/help

WAGemStoneRunSmalltalkServer addServerOfClass: ZnServer withName:
'myServer' on: #(8080).
(WAGemStoneRunSmalltalkServer serverNamed: 'myServer') start.

If I stop and remove the server with these two lines, it is gone:

WAGemStoneRunSmalltalkServer stopAllGems.
WAGemStoneRunSmalltalkServer removeServer: 'myServer'

If I execute the first two lines again I get a
"VM temporary object memory is full, old space overflow" - Error.

My session to Gemstone is invalid afterwards.

Does anybody else have those problems, or does anybody know what might
be wrong?

Thanks
Sebastian

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

This is the log for that test case.

Sebastian

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi all!

Okay my script seems to be wrong.

WAGemStoneRunSmalltalkServer addServerOfClass: ZnServer withName:
'myServer' on: #(9001).
WAGemStoneRunSmalltalkServer startGems: (WAGemStoneRunSmalltalkServer
serverNamed: 'myserver').

I wonder how you set delegates when using this?!

Do you write your own scripts into seaside/bin, or do you subclass ZnServer?

Cheers!
Sebastian
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Sebastian,

Sorry for not getting to you sooner .. I haven't really been using Zinc for anything other than running tests, so I'm not the best resource...

I looked at your log and it looks like you are using the multi-threaded Zinc server?

I am suspicious that the multi-threaded server is quite correctly ported to GemStone. Note that wehen you run the tests, there a whole bunch of threads hanging around[1].

The single threaded server seems to behave much better ... at least in tests ...

Not sure what folks are using in there Zinc installations ... I assume that the Seaside adaptor for Zinc uses the single threaded model, because we only run one request at a time in gem for transactional reasons ...

Dale

[1] https://github.com/glassdb/zinc/issues/42

----- Original Message -----
| From: "Sebastian Heidbrink" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, August 8, 2013 9:20:51 AM
| Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
|
| Hi all!
|
| Okay my script seems to be wrong.
|
| WAGemStoneRunSmalltalkServer addServerOfClass: ZnServer withName:
| 'myServer' on: #(9001).
| WAGemStoneRunSmalltalkServer startGems: (WAGemStoneRunSmalltalkServer
| serverNamed: 'myserver').
|
| I wonder how you set delegates when using this?!
|
| Do you write your own scripts into seaside/bin, or do you subclass
| ZnServer?
|
| Cheers!
| Sebastian
| _______________________________________________
| Glass mailing list
| [hidden email]
| http://lists.gemtalksystems.com/mailman/listinfo/glass
|
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Dale,

I tried it and I get the same result....

Meanwhile I realized that my script only works if I commit my
transaction prior to starting the gem like this:

"
WAGemStoneRunSmalltalkServer addServerOfClass: ZnServer withName:
'myserver' on: #(9001).
.... commit the transaction ...
WAGemStoneRunSmalltalkServer startGems: (WAGemStoneRunSmalltalkServer
serverNamed: 'myserver').
"

Otherwise the (WAGemStoneRunSmalltalkServer  serverNamed: 'myserver') is
nil in WAGemStoneRunSmalltalkServer startServer: serverName On: portInteger.

Since the remote debugging does not work with the currently delivered
runSmalltalkerver scriptsfor 3.1.0.4 I have to work with "halt" and
looking into the logs.

I already tried to change the script this way: see attached

It seems the listenloop is running, but I never end up in
"handleRequest" :-/

Sebastian


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Are you trying to run Seaside on Gemstone with Zinc or just run Zinc on
Gemstone for another purpose?






On 08/09/2013 08:51 AM, Sebastian Heidbrink wrote:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Paul,

I'm just trying to start Zinc on Gemstone for another purpose.

Sebastian

Am 09.08.2013 09:25, schrieb Paul DeBruicker:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

I was able to dive deeper and it seems like the "underlying" Socket of
SPSocket does not "accept"...

See SpSocket accept.

But calling localhost:9001 does only return "unable to connect"
Shouldn't I at least get the defaultDelegate results?

Sebastian


Am 09.08.2013 08:19, schrieb Dale K. Henrichs:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Sebastian,

To debug the setup, you should run:

  WAGemStoneRunSmalltalkServer startGemServer: '<servername>" On: <port number>.

in your GemTools image. Be aware that the above statement will block until you hit an error of some sort and you need to read the section on GemTools and processes[1] and some tips on working with servers[2]. For debugging out of memory problems, read the post on that topic[3].

If you do the above, the GemTools debugger will come up when you hit a problem either out of memory or an error ... doing the above you can set breakpoints or halts and the debugger will come up and you can track things down using normal development techniques ...

Once you get to the point where the server starts and runs normally, you will need to install some strategically placed error handlers so that you can arrange to snap off continuations and stash them in the Object Log for later debugging ... this is already done for you in Seaside...

Dale

[1] http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#GsProcesses
[2] http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#soaphttpdev
[3] http://gemstonesoup.wordpress.com/2008/11/19/gemstone-101-managing-out-of-memory-situations/
----- Original Message -----
| From: "Sebastian Heidbrink" <[hidden email]>
| To: [hidden email]
| Sent: Friday, August 9, 2013 8:51:17 AM
| Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
|
| Hi Dale,
|
| I tried it and I get the same result....
|
| Meanwhile I realized that my script only works if I commit my
| transaction prior to starting the gem like this:
|
| "
| WAGemStoneRunSmalltalkServer addServerOfClass: ZnServer withName:
| 'myserver' on: #(9001).
| .... commit the transaction ...
| WAGemStoneRunSmalltalkServer startGems: (WAGemStoneRunSmalltalkServer
| serverNamed: 'myserver').
| "
|
| Otherwise the (WAGemStoneRunSmalltalkServer  serverNamed: 'myserver')
| is
| nil in WAGemStoneRunSmalltalkServer startServer: serverName On:
| portInteger.
|
| Since the remote debugging does not work with the currently delivered
| runSmalltalkerver scriptsfor 3.1.0.4 I have to work with "halt" and
| looking into the logs.
|
| I already tried to change the script this way: see attached
|
| It seems the listenloop is running, but I never end up in
| "handleRequest" :-/
|
| Sebastian
|
|
| _______________________________________________
| Glass mailing list
| [hidden email]
| http://lists.gemtalksystems.com/mailman/listinfo/glass
|
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Dale,

thank you for the detailed information,... I tried to start my server
this way and I found out that in
"ZnRequestLine readFrom: stream " there's always only an empty string
resulting from "(ZnLineReader on: stream) nextLine"

This does not apply for the Unittests. Within those the read lines are
always properly filled.

I also have to start my request prior to starting the server....
otherwise nothing happens.

I'll keep searching for some more needful details.

Sebastian

Am 09.08.2013 10:20, schrieb Dale K. Henrichs:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Sebastian,

I don't know if this is a factor or not, but if you don't take great care in making sure that the sockets are all closed (by using stop server before starting another one) then you might start getting odd results ... especially during the phase where the bugs in the start/stop logic may not be completely worked out ...

Dale

----- Original Message -----
| From: "Sebastian Heidbrink" <[hidden email]>
| To: "Dale K. Henrichs" <[hidden email]>
| Cc: [hidden email]
| Sent: Saturday, August 10, 2013 4:28:44 PM
| Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
|
| Hi Dale,
|
| thank you for the detailed information,... I tried to start my server
| this way and I found out that in
| "ZnRequestLine readFrom: stream " there's always only an empty string
| resulting from "(ZnLineReader on: stream) nextLine"
|
| This does not apply for the Unittests. Within those the read lines
| are
| always properly filled.
|
| I also have to start my request prior to starting the server....
| otherwise nothing happens.
|
| I'll keep searching for some more needful details.
|
| Sebastian
|
| Am 09.08.2013 10:20, schrieb Dale K. Henrichs:
| > Sebastian,
| >
| > To debug the setup, you should run:
| >
| >    WAGemStoneRunSmalltalkServer startGemServer: '<servername>" On:
| >    <port number>.
| >
| > in your GemTools image. Be aware that the above statement will
| > block until you hit an error of some sort and you need to read the
| > section on GemTools and processes[1] and some tips on working with
| > servers[2]. For debugging out of memory problems, read the post on
| > that topic[3].
| >
| > If you do the above, the GemTools debugger will come up when you
| > hit a problem either out of memory or an error ... doing the above
| > you can set breakpoints or halts and the debugger will come up and
| > you can track things down using normal development techniques ...
| >
| > Once you get to the point where the server starts and runs
| > normally, you will need to install some strategically placed error
| > handlers so that you can arrange to snap off continuations and
| > stash them in the Object Log for later debugging ... this is
| > already done for you in Seaside...
| >
| > Dale
| >
| > [1]
| > http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#GsProcesses
| > [2]
| > http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#soaphttpdev
| > [3]
| > http://gemstonesoup.wordpress.com/2008/11/19/gemstone-101-managing-out-of-memory-situations/
| > ----- Original Message -----
| > | From: "Sebastian Heidbrink" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Friday, August 9, 2013 8:51:17 AM
| > | Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
| > |
| > | Hi Dale,
| > |
| > | I tried it and I get the same result....
| > |
| > | Meanwhile I realized that my script only works if I commit my
| > | transaction prior to starting the gem like this:
| > |
| > | "
| > | WAGemStoneRunSmalltalkServer addServerOfClass: ZnServer withName:
| > | 'myserver' on: #(9001).
| > | .... commit the transaction ...
| > | WAGemStoneRunSmalltalkServer startGems:
| > | (WAGemStoneRunSmalltalkServer
| > | serverNamed: 'myserver').
| > | "
| > |
| > | Otherwise the (WAGemStoneRunSmalltalkServer  serverNamed:
| > | 'myserver')
| > | is
| > | nil in WAGemStoneRunSmalltalkServer startServer: serverName On:
| > | portInteger.
| > |
| > | Since the remote debugging does not work with the currently
| > | delivered
| > | runSmalltalkerver scriptsfor 3.1.0.4 I have to work with "halt"
| > | and
| > | looking into the logs.
| > |
| > | I already tried to change the script this way: see attached
| > |
| > | It seems the listenloop is running, but I never end up in
| > | "handleRequest" :-/
| > |
| > | Sebastian
| > |
| > |
| > | _______________________________________________
| > | Glass mailing list
| > | [hidden email]
| > | http://lists.gemtalksystems.com/mailman/listinfo/glass
| > |
| >
|
|
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Dale,

well that is not the case.
When I get such issues the SUnit tests show the same errors and fail.
If I put a halt into the accept method of GSSocket I get different
behavior with the SUnits-tests and my manual start of the ZnServer.
The SUnit tests fire the halt and my manually started server does not :-/

Sebastian

Am 11.08.2013 08:39, schrieb Dale K. Henrichs:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Sebastian,

That is suspicious ... halt should halt if a halt is encountered, unless there is an exception handler on the stack ...

So you are saying that when you explicitly start ZnServer from a GemTools workspace the halt in the accept method is "swallowed" whereas the same expression in SUnit causes a debugger to pop up?

If this is the case then I would be inclined to halt immediately and step through the code to get to the bottom of things...

What expression do you use to "manually start" Zinc ... I will try to find time to take a look today ...

Dale
 
----- Original Message -----
| From: "Sebastian Heidbrink" <[hidden email]>
| To: [hidden email]
| Sent: Monday, August 12, 2013 9:37:17 AM
| Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
|
| Hi Dale,
|
| well that is not the case.
| When I get such issues the SUnit tests show the same errors and fail.
| If I put a halt into the accept method of GSSocket I get different
| behavior with the SUnits-tests and my manual start of the ZnServer.
| The SUnit tests fire the halt and my manually started server does not
| :-/
|
| Sebastian
|
| Am 11.08.2013 08:39, schrieb Dale K. Henrichs:
| > Sebastian,
| >
| > I don't know if this is a factor or not, but if you don't take
| > great care in making sure that the sockets are all closed (by
| > using stop server before starting another one) then you might
| > start getting odd results ... especially during the phase where
| > the bugs in the start/stop logic may not be completely worked out
| > ...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Sebastian Heidbrink" <[hidden email]>
| > | To: "Dale K. Henrichs" <[hidden email]>
| > | Cc: [hidden email]
| > | Sent: Saturday, August 10, 2013 4:28:44 PM
| > | Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
| > |
| > | Hi Dale,
| > |
| > | thank you for the detailed information,... I tried to start my
| > | server
| > | this way and I found out that in
| > | "ZnRequestLine readFrom: stream " there's always only an empty
| > | string
| > | resulting from "(ZnLineReader on: stream) nextLine"
| > |
| > | This does not apply for the Unittests. Within those the read
| > | lines
| > | are
| > | always properly filled.
| > |
| > | I also have to start my request prior to starting the server....
| > | otherwise nothing happens.
| > |
| > | I'll keep searching for some more needful details.
| > |
| > | Sebastian
| > |
| > | Am 09.08.2013 10:20, schrieb Dale K. Henrichs:
| > | > Sebastian,
| > | >
| > | > To debug the setup, you should run:
| > | >
| > | >    WAGemStoneRunSmalltalkServer startGemServer: '<servername>"
| > | >    On:
| > | >    <port number>.
| > | >
| > | > in your GemTools image. Be aware that the above statement will
| > | > block until you hit an error of some sort and you need to read
| > | > the
| > | > section on GemTools and processes[1] and some tips on working
| > | > with
| > | > servers[2]. For debugging out of memory problems, read the post
| > | > on
| > | > that topic[3].
| > | >
| > | > If you do the above, the GemTools debugger will come up when
| > | > you
| > | > hit a problem either out of memory or an error ... doing the
| > | > above
| > | > you can set breakpoints or halts and the debugger will come up
| > | > and
| > | > you can track things down using normal development techniques
| > | > ...
| > | >
| > | > Once you get to the point where the server starts and runs
| > | > normally, you will need to install some strategically placed
| > | > error
| > | > handlers so that you can arrange to snap off continuations and
| > | > stash them in the Object Log for later debugging ... this is
| > | > already done for you in Seaside...
| > | >
| > | > Dale
| > | >
| > | > [1]
| > | > http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#GsProcesses
| > | > [2]
| > | > http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#soaphttpdev
| > | > [3]
| > | > http://gemstonesoup.wordpress.com/2008/11/19/gemstone-101-managing-out-of-memory-situations/
| > | > ----- Original Message -----
| > | > | From: "Sebastian Heidbrink" <[hidden email]>
| > | > | To: [hidden email]
| > | > | Sent: Friday, August 9, 2013 8:51:17 AM
| > | > | Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
| > | > |
| > | > | Hi Dale,
| > | > |
| > | > | I tried it and I get the same result....
| > | > |
| > | > | Meanwhile I realized that my script only works if I commit my
| > | > | transaction prior to starting the gem like this:
| > | > |
| > | > | "
| > | > | WAGemStoneRunSmalltalkServer addServerOfClass: ZnServer
| > | > | withName:
| > | > | 'myserver' on: #(9001).
| > | > | .... commit the transaction ...
| > | > | WAGemStoneRunSmalltalkServer startGems:
| > | > | (WAGemStoneRunSmalltalkServer
| > | > | serverNamed: 'myserver').
| > | > | "
| > | > |
| > | > | Otherwise the (WAGemStoneRunSmalltalkServer  serverNamed:
| > | > | 'myserver')
| > | > | is
| > | > | nil in WAGemStoneRunSmalltalkServer startServer: serverName
| > | > | On:
| > | > | portInteger.
| > | > |
| > | > | Since the remote debugging does not work with the currently
| > | > | delivered
| > | > | runSmalltalkerver scriptsfor 3.1.0.4 I have to work with
| > | > | "halt"
| > | > | and
| > | > | looking into the logs.
| > | > |
| > | > | I already tried to change the script this way: see attached
| > | > |
| > | > | It seems the listenloop is running, but I never end up in
| > | > | "handleRequest" :-/
| > | > |
| > | > | Sebastian
| > | > |
| > | > |
| > | > | _______________________________________________
| > | > | Glass mailing list
| > | > | [hidden email]
| > | > | http://lists.gemtalksystems.com/mailman/listinfo/glass
| > | > |
| > | >
| > |
| > |
| >
|
| _______________________________________________
| Glass mailing list
| [hidden email]
| http://lists.gemtalksystems.com/mailman/listinfo/glass
|
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Okay,...

Everything is fine,... I was missing the infinit loop in my start
scripts in general...

Thanks for the help Dale!

Zinc on Gemstone seems good to go! Just the /status page of the
DefaultDelegate seems to have a problem...

Sebastian


Am 12.08.2013 09:53, schrieb Dale K. Henrichs:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

I'm glad you are moving forward again!

Dale

----- Original Message -----
| From: "Sebastian Heidbrink" <[hidden email]>
| To: "Dale K. Henrichs" <[hidden email]>
| Cc: [hidden email]
| Sent: Tuesday, August 13, 2013 8:22:17 AM
| Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
|
| Okay,...
|
| Everything is fine,... I was missing the infinit loop in my start
| scripts in general...
|
| Thanks for the help Dale!
|
| Zinc on Gemstone seems good to go! Just the /status page of the
| DefaultDelegate seems to have a problem...
|
| Sebastian
|
|
| Am 12.08.2013 09:53, schrieb Dale K. Henrichs:
| > Sebastian,
| >
| > That is suspicious ... halt should halt if a halt is encountered,
| > unless there is an exception handler on the stack ...
| >
| > So you are saying that when you explicitly start ZnServer from a
| > GemTools workspace the halt in the accept method is "swallowed"
| > whereas the same expression in SUnit causes a debugger to pop up?
| >
| > If this is the case then I would be inclined to halt immediately
| > and step through the code to get to the bottom of things...
| >
| > What expression do you use to "manually start" Zinc ... I will try
| > to find time to take a look today ...
| >
| > Dale
| >  
| > ----- Original Message -----
| > | From: "Sebastian Heidbrink" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Monday, August 12, 2013 9:37:17 AM
| > | Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
| > |
| > | Hi Dale,
| > |
| > | well that is not the case.
| > | When I get such issues the SUnit tests show the same errors and
| > | fail.
| > | If I put a halt into the accept method of GSSocket I get
| > | different
| > | behavior with the SUnits-tests and my manual start of the
| > | ZnServer.
| > | The SUnit tests fire the halt and my manually started server does
| > | not
| > | :-/
| > |
| > | Sebastian
| > |
| > | Am 11.08.2013 08:39, schrieb Dale K. Henrichs:
| > | > Sebastian,
| > | >
| > | > I don't know if this is a factor or not, but if you don't take
| > | > great care in making sure that the sockets are all closed (by
| > | > using stop server before starting another one) then you might
| > | > start getting odd results ... especially during the phase where
| > | > the bugs in the start/stop logic may not be completely worked
| > | > out
| > | > ...
| > | >
| > | > Dale
| > | >
| > | > ----- Original Message -----
| > | > | From: "Sebastian Heidbrink" <[hidden email]>
| > | > | To: "Dale K. Henrichs" <[hidden email]>
| > | > | Cc: [hidden email]
| > | > | Sent: Saturday, August 10, 2013 4:28:44 PM
| > | > | Subject: Re: [Glass] [3.1.0.4] WAGemStoneRunSmalltalkServer
| > | > |
| > | > | Hi Dale,
| > | > |
| > | > | thank you for the detailed information,... I tried to start
| > | > | my
| > | > | server
| > | > | this way and I found out that in
| > | > | "ZnRequestLine readFrom: stream " there's always only an
| > | > | empty
| > | > | string
| > | > | resulting from "(ZnLineReader on: stream) nextLine"
| > | > |
| > | > | This does not apply for the Unittests. Within those the read
| > | > | lines
| > | > | are
| > | > | always properly filled.
| > | > |
| > | > | I also have to start my request prior to starting the
| > | > | server....
| > | > | otherwise nothing happens.
| > | > |
| > | > | I'll keep searching for some more needful details.
| > | > |
| > | > | Sebastian
| > | > |
| > | > | Am 09.08.2013 10:20, schrieb Dale K. Henrichs:
| > | > | > Sebastian,
| > | > | >
| > | > | > To debug the setup, you should run:
| > | > | >
| > | > | >    WAGemStoneRunSmalltalkServer startGemServer:
| > | > | >    '<servername>"
| > | > | >    On:
| > | > | >    <port number>.
| > | > | >
| > | > | > in your GemTools image. Be aware that the above statement
| > | > | > will
| > | > | > block until you hit an error of some sort and you need to
| > | > | > read
| > | > | > the
| > | > | > section on GemTools and processes[1] and some tips on
| > | > | > working
| > | > | > with
| > | > | > servers[2]. For debugging out of memory problems, read the
| > | > | > post
| > | > | > on
| > | > | > that topic[3].
| > | > | >
| > | > | > If you do the above, the GemTools debugger will come up
| > | > | > when
| > | > | > you
| > | > | > hit a problem either out of memory or an error ... doing
| > | > | > the
| > | > | > above
| > | > | > you can set breakpoints or halts and the debugger will come
| > | > | > up
| > | > | > and
| > | > | > you can track things down using normal development
| > | > | > techniques
| > | > | > ...
| > | > | >
| > | > | > Once you get to the point where the server starts and runs
| > | > | > normally, you will need to install some strategically
| > | > | > placed
| > | > | > error
| > | > | > handlers so that you can arrange to snap off continuations
| > | > | > and
| > | > | > stash them in the Object Log for later debugging ... this
| > | > | > is
| > | > | > already done for you in Seaside...
| > | > | >
| > | > | > Dale
| > | > | >
| > | > | > [1]
| > | > | > http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#GsProcesses
| > | > | > [2]
| > | > | > http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#soaphttpdev
| > | > | > [3]
| > | > | > http://gemstonesoup.wordpress.com/2008/11/19/gemstone-101-managing-out-of-memory-situations/
| > | > | > ----- Original Message -----
| > | > | > | From: "Sebastian Heidbrink"
| > | > | > | <[hidden email]>
| > | > | > | To: [hidden email]
| > | > | > | Sent: Friday, August 9, 2013 8:51:17 AM
| > | > | > | Subject: Re: [Glass] [3.1.0.4]
| > | > | > | WAGemStoneRunSmalltalkServer
| > | > | > |
| > | > | > | Hi Dale,
| > | > | > |
| > | > | > | I tried it and I get the same result....
| > | > | > |
| > | > | > | Meanwhile I realized that my script only works if I
| > | > | > | commit my
| > | > | > | transaction prior to starting the gem like this:
| > | > | > |
| > | > | > | "
| > | > | > | WAGemStoneRunSmalltalkServer addServerOfClass: ZnServer
| > | > | > | withName:
| > | > | > | 'myserver' on: #(9001).
| > | > | > | .... commit the transaction ...
| > | > | > | WAGemStoneRunSmalltalkServer startGems:
| > | > | > | (WAGemStoneRunSmalltalkServer
| > | > | > | serverNamed: 'myserver').
| > | > | > | "
| > | > | > |
| > | > | > | Otherwise the (WAGemStoneRunSmalltalkServer  serverNamed:
| > | > | > | 'myserver')
| > | > | > | is
| > | > | > | nil in WAGemStoneRunSmalltalkServer startServer:
| > | > | > | serverName
| > | > | > | On:
| > | > | > | portInteger.
| > | > | > |
| > | > | > | Since the remote debugging does not work with the
| > | > | > | currently
| > | > | > | delivered
| > | > | > | runSmalltalkerver scriptsfor 3.1.0.4 I have to work with
| > | > | > | "halt"
| > | > | > | and
| > | > | > | looking into the logs.
| > | > | > |
| > | > | > | I already tried to change the script this way: see
| > | > | > | attached
| > | > | > |
| > | > | > | It seems the listenloop is running, but I never end up in
| > | > | > | "handleRequest" :-/
| > | > | > |
| > | > | > | Sebastian
| > | > | > |
| > | > | > |
| > | > | > | _______________________________________________
| > | > | > | Glass mailing list
| > | > | > | [hidden email]
| > | > | > | http://lists.gemtalksystems.com/mailman/listinfo/glass
| > | > | > |
| > | > | >
| > | > |
| > | > |
| > | >
| > |
| > | _______________________________________________
| > | Glass mailing list
| > | [hidden email]
| > | http://lists.gemtalksystems.com/mailman/listinfo/glass
| > |
| >
|
|
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi,

I encounter some problems using NeoCSV on Gemstone.
I importet float via CSV into Gemstone and now I want to export them
again, but "asString" presents the float value in scientific format.

How come that '3.651666667' asFloat inspects with the same printString
but asString wich calls asString returns: '3.6516666670000002E+00' this
is just a small difference, but in my case it is too big since I need to
do reprocessing in the client and that adds addtional issues...

'3.651666667' asFloat asStringUsingFormat: #(1 7 false)
seems to work, but this makes me wonder which printString method the
Inspector in Jade uses?

Thanks
Sebastian
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Sebastian,

This is an interesting subtle issue. It turns out that Jade evaluates the expression on the server (sending #’asFloat’ to an instance of String) and gets back an OOP. As a second step it decides what to do with the OOP. The Inspect (or Print It) command require a string representation. Since it is a special (an instance of SmallDouble is encoded entirely in the OOP) we don’t bother to go back to the server to send the #’printString’ method but instead send the message on the client. So, a SmallDouble gets unpacked as a Float in Dolphin and the #’printString’ message is evaluated by Dolphin to give the display format without the exponent. So, we aren’t using any GemStone code to convert the SmallDouble to a String! That is what leads to your confusion.

James

On Dec 27, 2013, at 4:17 PM, Sebastian Heidbrink <[hidden email]> wrote:

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass