Info on implementation limits

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

Hello Christian,

well, the size of such a file is not a problem. In one of our projects, the source code file of my automatically generated model has a size of around 8.7 MByte.

Marten

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

Christian,

Could you send me the full topaz log file? We need that to understand what might be going on ...

Thanks,

Dale

Hi,

 

are there any information about implementation limits of Gemstone Smalltalk?

 

Concrete issue:

I try to input a source file (2.1. MB – can this work?).

Topaz dies (Windows reports that Topaz is not working anymore…)

Last thing in the log file is a method with 743 literals – is this an issue?

My naïve theory: Gemstone (Topaz?) cannot compile the method, but dies without error.

 

Any ideas?

 

Thanks,

                Christian

 

_______________________________________________
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

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

Thanks Christian. We'll let you know what we find out ...

Dale

(resent, because Google blocked the attachment)

 

Von: Christian Haider [[hidden email]]
Gesendet: Mittwoch, 12. Juli 2017 09:53
An: '[hidden email]' [hidden email]
Cc: 'Dale Henrichs' [hidden email]
Betreff: AW: [Glass] Info on implementation limits

 

From replies off list, I heard, that big input files are not a problem. Good to know, thank you.

 

For the crash on the big method, I investigated and created an input file which reproduces the problem (attached as bigMethod.gs). The log is attached as well.

My theory was wrong. It seems not to be a problem with many literals in a method, but something else.

When I input the file in a Topaz shell (on windows), it works seamless and the method can be called.

Steps:

1. Login to topaz
2. enter ‘output push c:\image\bigMethod.log’[CR]
3. enter ‘input c:\image\bigMethod.gs’[CR]
4. all fine!

 

But if I do the same with a batch file which uses the script loadBigMethod.tpz (attached),

The Topaz window opens, it stays there for about 10 seconds (the step 3 above took no time) and the crashes (Windows pops up with “the program does not work anymore…” or something like that (I have a German version).

 

Any idea?

Thanks

 

 

Config data (running on Windows 10):

|    PROGRAM: topaz, Linear GemStone Interface (Remote Session)               |

|    VERSION: 3.3.5, Thu May  4 11:44:37 2017                                 |

|      BUILD: gss64_3_3_x_branch-41643                                        |

|  BUILT FOR: x86-64/Windows7                                                 |

|       MODE: 64 bit                                                          |

| RUNNING ON: 4-CPU haider-pc: Unknown CPU, Windows NT 6.2 build 9200         |

 

 

Von: Glass [[hidden email]] Im Auftrag von Dale Henrichs via Glass
Gesendet: Dienstag, 11. Juli 2017 18:20
An: [hidden email]
Betreff: Re: [Glass] Info on implementation limits

 

Christian,

Could you send me the full topaz log file? We need that to understand what might be going on ...

Thanks,

Dale

 

On 7/11/17 1:07 AM, Christian Haider via Glass wrote:

Hi,

 

are there any information about implementation limits of Gemstone Smalltalk?

 

Concrete issue:

I try to input a source file (2.1. MB – can this work?).

Topaz dies (Windows reports that Topaz is not working anymore…)

Last thing in the log file is a method with 743 literals – is this an issue?

My naïve theory: Gemstone (Topaz?) cannot compile the method, but dies without error.

 

Any ideas?

 

Thanks,

                Christian

 

_______________________________________________

Glass mailing list

[hidden email]

http://lists.gemtalksystems.com/mailman/listinfo/glass

 

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

Christian,

Can you provide more details, so we can try to check this one out? Log file, method source, etc.

Thanks,

Dale

Found another one (sudden death):

A method returning a literal 78 KB String.

What is the limit on the method source size?

Or, is there a limit for strings inside a method?

 

Cheers,

                Christian

 

Von: Glass [[hidden email]] Im Auftrag von Christian Haider via Glass
Gesendet: Mittwoch, 12. Juli 2017 11:37
An: [hidden email]
Betreff: [Glass] WG: Info on implementation limits

 

(resent, because Google blocked the attachment)

 

Von: Christian Haider [[hidden email]]
Gesendet: Mittwoch, 12. Juli 2017 09:53
An: '[hidden email]' <[hidden email]>
Cc: 'Dale Henrichs' <[hidden email]>
Betreff: AW: [Glass] Info on implementation limits

 

From replies off list, I heard, that big input files are not a problem. Good to know, thank you.

 

For the crash on the big method, I investigated and created an input file which reproduces the problem (attached as bigMethod.gs). The log is attached as well.

My theory was wrong. It seems not to be a problem with many literals in a method, but something else.

When I input the file in a Topaz shell (on windows), it works seamless and the method can be called.

Steps:

1. Login to topaz
2. enter ‘output push c:\image\bigMethod.log’[CR]
3. enter ‘input c:\image\bigMethod.gs’[CR]
4. all fine!

 

But if I do the same with a batch file which uses the script loadBigMethod.tpz (attached),

The Topaz window opens, it stays there for about 10 seconds (the step 3 above took no time) and the crashes (Windows pops up with “the program does not work anymore…” or something like that (I have a German version).

 

Any idea?

Thanks

 

 

Config data (running on Windows 10):

|    PROGRAM: topaz, Linear GemStone Interface (Remote Session)               |

|    VERSION: 3.3.5, Thu May  4 11:44:37 2017                                 |

|      BUILD: gss64_3_3_x_branch-41643                                        |

|  BUILT FOR: x86-64/Windows7                                                 |

|       MODE: 64 bit                                                          |

| RUNNING ON: 4-CPU haider-pc: Unknown CPU, Windows NT 6.2 build 9200         |

 

 

Von: Glass [[hidden email]] Im Auftrag von Dale Henrichs via Glass
Gesendet: Dienstag, 11. Juli 2017 18:20
An: [hidden email]
Betreff: Re: [Glass] Info on implementation limits

 

Christian,

Could you send me the full topaz log file? We need that to understand what might be going on ...

Thanks,

Dale

 

On 7/11/17 1:07 AM, Christian Haider via Glass wrote:

Hi,

 

are there any information about implementation limits of Gemstone Smalltalk?

 

Concrete issue:

I try to input a source file (2.1. MB – can this work?).

Topaz dies (Windows reports that Topaz is not working anymore…)

Last thing in the log file is a method with 743 literals – is this an issue?

My naïve theory: Gemstone (Topaz?) cannot compile the method, but dies without error.

 

Any ideas?

 

Thanks,

                Christian

 

 

_______________________________________________

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

Dale,

 

attached is the source method from VW – I found a much smaller one (4022 Byte literal string) with the same problem.

The setup is identical with the prior problem.

Thanks for the source ...

 

So, there are no simple answers to the limits questions?

I don't have the specific limits memorized and I have passed your questions along to folks who know where to look, however, they are more focused on trying to understand why the sessions disappeared without a trace ... I would have expected that you'd have gotten an error message if you exceeded any limits ...

Dale

 

Cheers,

                Christian

 

Von: Dale Henrichs [[hidden email]]
Gesendet: Mittwoch, 12. Juli 2017 15:50
An: Christian Haider [hidden email]; [hidden email]
Betreff: Re: AW: [Glass] WG: Info on implementation limits

 

Christian,

Can you provide more details, so we can try to check this one out? Log file, method source, etc.

Thanks,

Dale

 

On 7/12/17 6:18 AM, Christian Haider wrote:

Found another one (sudden death):

A method returning a literal 78 KB String.

What is the limit on the method source size?

Or, is there a limit for strings inside a method?

 

Cheers,

                Christian

 

Von: Glass [[hidden email]] Im Auftrag von Christian Haider via Glass
Gesendet: Mittwoch, 12. Juli 2017 11:37
An: [hidden email]
Betreff: [Glass] WG: Info on implementation limits

 

(resent, because Google blocked the attachment)

 

Von: Christian Haider [[hidden email]]
Gesendet: Mittwoch, 12. Juli 2017 09:53
An: '[hidden email]' <[hidden email]>
Cc: 'Dale Henrichs' <[hidden email]>
Betreff: AW: [Glass] Info on implementation limits

 

From replies off list, I heard, that big input files are not a problem. Good to know, thank you.

 

For the crash on the big method, I investigated and created an input file which reproduces the problem (attached as bigMethod.gs). The log is attached as well.

My theory was wrong. It seems not to be a problem with many literals in a method, but something else.

When I input the file in a Topaz shell (on windows), it works seamless and the method can be called.

Steps:

1. Login to topaz
2. enter ‘output push c:\image\bigMethod.log’[CR]
3. enter ‘input c:\image\bigMethod.gs’[CR]
4. all fine!

 

But if I do the same with a batch file which uses the script loadBigMethod.tpz (attached),

The Topaz window opens, it stays there for about 10 seconds (the step 3 above took no time) and the crashes (Windows pops up with “the program does not work anymore…” or something like that (I have a German version).

 

Any idea?

Thanks

 

 

Config data (running on Windows 10):

|    PROGRAM: topaz, Linear GemStone Interface (Remote Session)               |

|    VERSION: 3.3.5, Thu May  4 11:44:37 2017                                 |

|      BUILD: gss64_3_3_x_branch-41643                                        |

|  BUILT FOR: x86-64/Windows7                                                 |

|       MODE: 64 bit                                                          |

| RUNNING ON: 4-CPU haider-pc: Unknown CPU, Windows NT 6.2 build 9200         |

 

 

Von: Glass [[hidden email]] Im Auftrag von Dale Henrichs via Glass
Gesendet: Dienstag, 11. Juli 2017 18:20
An: [hidden email]
Betreff: Re: [Glass] Info on implementation limits

 

Christian,

Could you send me the full topaz log file? We need that to understand what might be going on ...

Thanks,

Dale

 

On 7/11/17 1:07 AM, Christian Haider via Glass wrote:

Hi,

 

are there any information about implementation limits of Gemstone Smalltalk?

 

Concrete issue:

I try to input a source file (2.1. MB – can this work?).

Topaz dies (Windows reports that Topaz is not working anymore…)

Last thing in the log file is a method with 743 literals – is this an issue?

My naïve theory: Gemstone (Topaz?) cannot compile the method, but dies without error.

 

Any ideas?

 

Thanks,

                Christian

 

 

_______________________________________________

Glass mailing list

[hidden email]

http://lists.gemtalksystems.com/mailman/listinfo/glass

 

 

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

Christian,

From engineering:

   I suspect that topaz echo of output

Dale

Dale,

 

attached is the source method from VW – I found a much smaller one (4022 Byte literal string) with the same problem.

The setup is identical with the prior problem.

 

So, there are no simple answers to the limits questions?

 

Cheers,

                Christian

 

Von: Dale Henrichs [[hidden email]]
Gesendet: Mittwoch, 12. Juli 2017 15:50
An: Christian Haider [hidden email]; [hidden email]
Betreff: Re: AW: [Glass] WG: Info on implementation limits

 

Christian,

Can you provide more details, so we can try to check this one out? Log file, method source, etc.

Thanks,

Dale

 

On 7/12/17 6:18 AM, Christian Haider wrote:

Found another one (sudden death):

A method returning a literal 78 KB String.

What is the limit on the method source size?

Or, is there a limit for strings inside a method?

 

Cheers,

                Christian

 

Von: Glass [[hidden email]] Im Auftrag von Christian Haider via Glass
Gesendet: Mittwoch, 12. Juli 2017 11:37
An: [hidden email]
Betreff: [Glass] WG: Info on implementation limits

 

(resent, because Google blocked the attachment)

 

Von: Christian Haider [[hidden email]]
Gesendet: Mittwoch, 12. Juli 2017 09:53
An: '[hidden email]' <[hidden email]>
Cc: 'Dale Henrichs' <[hidden email]>
Betreff: AW: [Glass] Info on implementation limits

 

From replies off list, I heard, that big input files are not a problem. Good to know, thank you.

 

For the crash on the big method, I investigated and created an input file which reproduces the problem (attached as bigMethod.gs). The log is attached as well.

My theory was wrong. It seems not to be a problem with many literals in a method, but something else.

When I input the file in a Topaz shell (on windows), it works seamless and the method can be called.

Steps:

1. Login to topaz
2. enter ‘output push c:\image\bigMethod.log’[CR]
3. enter ‘input c:\image\bigMethod.gs’[CR]
4. all fine!

 

But if I do the same with a batch file which uses the script loadBigMethod.tpz (attached),

The Topaz window opens, it stays there for about 10 seconds (the step 3 above took no time) and the crashes (Windows pops up with “the program does not work anymore…” or something like that (I have a German version).

 

Any idea?

Thanks

 

 

Config data (running on Windows 10):

|    PROGRAM: topaz, Linear GemStone Interface (Remote Session)               |

|    VERSION: 3.3.5, Thu May  4 11:44:37 2017                                 |

|      BUILD: gss64_3_3_x_branch-41643                                        |

|  BUILT FOR: x86-64/Windows7                                                 |

|       MODE: 64 bit                                                          |

| RUNNING ON: 4-CPU haider-pc: Unknown CPU, Windows NT 6.2 build 9200         |

 

 

Von: Glass [[hidden email]] Im Auftrag von Dale Henrichs via Glass
Gesendet: Dienstag, 11. Juli 2017 18:20
An: [hidden email]
Betreff: Re: [Glass] Info on implementation limits

 

Christian,

Could you send me the full topaz log file? We need that to understand what might be going on ...

Thanks,

Dale

 

On 7/11/17 1:07 AM, Christian Haider via Glass wrote:

Hi,

 

are there any information about implementation limits of Gemstone Smalltalk?

 

Concrete issue:

I try to input a source file (2.1. MB – can this work?).

Topaz dies (Windows reports that Topaz is not working anymore…)

Last thing in the log file is a method with 743 literals – is this an issue?

My naïve theory: Gemstone (Topaz?) cannot compile the method, but dies without error.

 

Any ideas?

 

Thanks,

                Christian

 

 

_______________________________________________

Glass mailing list

[hidden email]

http://lists.gemtalksystems.com/mailman/listinfo/glass

 

 

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

Dale,

 

attached is the source method from VW – I found a much smaller one (4022 Byte literal string) with the same problem.

The setup is identical with the prior problem.

 

So, there are no simple answers to the limits questions?

From engineering:


Dale

_______________________________________________
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