What's up on build.squeak.org

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

What's up on build.squeak.org

Nicolas Cellier
Hi,
it seems that most of the builds are red for 2 months.
I checked the last artefact for squeak trunk:
http://build.squeak.org/job/SqueakTrunk/853/

It's still blocked with the [Warning signal: 'About to serialize an empty package.']
With this warning, a test never time out (I don't know why exactly, but it seems that theProcess monitored by the timeout watchdog is already suspended by the Warning)
As a result, the tests do never complete and are aborted after 20 minutes...

Chris has fixed the problem since, but it seems that the CI does not upload latest trunk.
Why?
It seems to be the same problem as the TestRunner: updating triggers the same [Warning signal: 'About to serialize an empty package.']
Ah Chris, it's irony that it's you who precisely keep on fighting modal UI ;)

Now the question: how do we escape from this situation?
Shall I cheat and modify the update that is blocking?




Reply | Threaded
Open this post in threaded view
|

Re: What's up on build.squeak.org

Nicolas Cellier

2014-05-24 22:36 GMT+02:00 Nicolas Cellier <[hidden email]>:
Hi,
it seems that most of the builds are red for 2 months.
I checked the last artefact for squeak trunk:
http://build.squeak.org/job/SqueakTrunk/853/

It's still blocked with the [Warning signal: 'About to serialize an empty package.']
With this warning, a test never time out (I don't know why exactly, but it seems that theProcess monitored by the timeout watchdog is already suspended by the Warning)
As a result, the tests do never complete and are aborted after 20 minutes...

Chris has fixed the problem since, but it seems that the CI does not upload latest trunk.
Why?
It seems to be the same problem as the TestRunner: updating triggers the same [Warning signal: 'About to serialize an empty package.']
Ah Chris, it's irony that it's you who precisely keep on fighting modal UI ;)

Now the question: how do we escape from this situation?
Shall I cheat and modify the update that is blocking?


So I decided to cheat:
I brought update-eem.279 to the surgery block and reverted CommandLine-fbs.3 -> CommandLine-fbs.2
CommandLine-fbs.3 tried to be smart and workaround the Warning problem, but before it had a chance to load, it precisely triggered this Warning!!!
Since this update is also bringing Chris fix, let's defer CommandLine-fbs.3 to next update (eem-280) and cross fingers...



Reply | Threaded
Open this post in threaded view
|

Re: What's up on build.squeak.org

Nicolas Cellier
Ah, no, the build is still failing!
Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem with:
MCClassDefinition>>createClass
I encountered this one while updating some of my old trunk images.
The definition changed in Monticello-cwp.589:
+                       inEnvironment: (CurrentEnvironment signal ifNil: [superClass environment])
-                       inEnvironment: (EnvironmentRequest signal ifNil: [superClass environment])

But there is no EnvironmentRequest anymore when loading this definition, so we signal nil, and the load fails.
We would have expected this, it's just be renamed in:

Environments-cwp.47
Time: 22 March 2014, 7:53:17.666 pm
Rename EnvironmentRequest to CurrentEnvironment and use it to implement Environment class>>current.

To be safe, the rename should have been performed in two stages:
1) create the new class and migrate customers from the old to the new one.
2) remove the old one
It would thus have required two updates.mcm and not a single one
(MC lacks a semantic #rename: so it does not work like in-image-tools)
Unfortunately, update-cwp.48 did perform the two operations at once...

Curiously, if I take an artefact from build server and update, the upgrade is then processing fine... Don't ask why.
Since no one complained, I told to myself that it was me not following the standard process, I patched my images manually and restarted the upgrade.
But I now see that it's not just me, there is a CI machine too using Squeak trunk (anyone else???)

I have to cheat again with mcm surgery:
- publish an Environments-nice.47 that adds the CurrentEnvironment, but not removes EnvironmentRequest
- patch update-cwp.48 to point to Environments-nice.47 rather than Environments-cwp.47
That'll be in a few minutes...


2014-05-24 22:58 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-05-24 22:36 GMT+02:00 Nicolas Cellier <[hidden email]>:

Hi,
it seems that most of the builds are red for 2 months.
I checked the last artefact for squeak trunk:
http://build.squeak.org/job/SqueakTrunk/853/

It's still blocked with the [Warning signal: 'About to serialize an empty package.']
With this warning, a test never time out (I don't know why exactly, but it seems that theProcess monitored by the timeout watchdog is already suspended by the Warning)
As a result, the tests do never complete and are aborted after 20 minutes...

Chris has fixed the problem since, but it seems that the CI does not upload latest trunk.
Why?
It seems to be the same problem as the TestRunner: updating triggers the same [Warning signal: 'About to serialize an empty package.']
Ah Chris, it's irony that it's you who precisely keep on fighting modal UI ;)

Now the question: how do we escape from this situation?
Shall I cheat and modify the update that is blocking?


So I decided to cheat:
I brought update-eem.279 to the surgery block and reverted CommandLine-fbs.3 -> CommandLine-fbs.2
CommandLine-fbs.3 tried to be smart and workaround the Warning problem, but before it had a chance to load, it precisely triggered this Warning!!!
Since this update is also bringing Chris fix, let's defer CommandLine-fbs.3 to next update (eem-280) and cross fingers...




Reply | Threaded
Open this post in threaded view
|

Re: What's up on build.squeak.org

Nicolas Cellier
OK, build.squeak.org, I have to admit, you win... http://build.squeak.org/job/SqueakTrunk/855/console
Ddin't we see this failure already?

Segmentation fault Sun May 25 00:39:10 2014 Squeak VM version: 4.0-2776 #1 Thu Aug 22 10:35:56 PDT 2013 gcc 4.1.2 [Production ITHB VM] Built from: CoInterpreter VMMaker.oscog-eem.331 uuid: 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013 With: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid: 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013 Revision: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Build host: Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686 i686 i386 GNU/Linux plugin path: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776 [default: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/lib/squeak/4.0-2776/] C stack backtrace: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d051] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d228] [0xf57fe40c] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x80e5a59] [0x473c7848] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(interpret+0x1eb)[0x808107b] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(main+0x397)[0x805d717] /lib/i686/nosegneg/libc.so.6(__libc_start_main+0xe6)[0xb7560ca6] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805b101] Smalltalk stack dump: 0xbfa178a4 M LargePositiveInteger>\\ 0x4899127c: a(n) LargePositiveInteger


2014-05-25 0:06 GMT+02:00 Nicolas Cellier <[hidden email]>:
Ah, no, the build is still failing!
Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem with:
MCClassDefinition>>createClass
I encountered this one while updating some of my old trunk images.
The definition changed in Monticello-cwp.589:
+                       inEnvironment: (CurrentEnvironment signal ifNil: [superClass environment])
-                       inEnvironment: (EnvironmentRequest signal ifNil: [superClass environment])

But there is no EnvironmentRequest anymore when loading this definition, so we signal nil, and the load fails.
We would have expected this, it's just be renamed in:

Environments-cwp.47
Time: 22 March 2014, 7:53:17.666 pm
Rename EnvironmentRequest to CurrentEnvironment and use it to implement Environment class>>current.

To be safe, the rename should have been performed in two stages:
1) create the new class and migrate customers from the old to the new one.
2) remove the old one
It would thus have required two updates.mcm and not a single one
(MC lacks a semantic #rename: so it does not work like in-image-tools)
Unfortunately, update-cwp.48 did perform the two operations at once...

Curiously, if I take an artefact from build server and update, the upgrade is then processing fine... Don't ask why.
Since no one complained, I told to myself that it was me not following the standard process, I patched my images manually and restarted the upgrade.
But I now see that it's not just me, there is a CI machine too using Squeak trunk (anyone else???)

I have to cheat again with mcm surgery:
- publish an Environments-nice.47 that adds the CurrentEnvironment, but not removes EnvironmentRequest
- patch update-cwp.48 to point to Environments-nice.47 rather than Environments-cwp.47
That'll be in a few minutes...


2014-05-24 22:58 GMT+02:00 Nicolas Cellier <[hidden email]>:


2014-05-24 22:36 GMT+02:00 Nicolas Cellier <[hidden email]>:

Hi,
it seems that most of the builds are red for 2 months.
I checked the last artefact for squeak trunk:
http://build.squeak.org/job/SqueakTrunk/853/

It's still blocked with the [Warning signal: 'About to serialize an empty package.']
With this warning, a test never time out (I don't know why exactly, but it seems that theProcess monitored by the timeout watchdog is already suspended by the Warning)
As a result, the tests do never complete and are aborted after 20 minutes...

Chris has fixed the problem since, but it seems that the CI does not upload latest trunk.
Why?
It seems to be the same problem as the TestRunner: updating triggers the same [Warning signal: 'About to serialize an empty package.']
Ah Chris, it's irony that it's you who precisely keep on fighting modal UI ;)

Now the question: how do we escape from this situation?
Shall I cheat and modify the update that is blocking?


So I decided to cheat:
I brought update-eem.279 to the surgery block and reverted CommandLine-fbs.3 -> CommandLine-fbs.2
CommandLine-fbs.3 tried to be smart and workaround the Warning problem, but before it had a chance to load, it precisely triggered this Warning!!!
Since this update is also bringing Chris fix, let's defer CommandLine-fbs.3 to next update (eem-280) and cross fingers...





Reply | Threaded
Open this post in threaded view
|

Re: What's up on build.squeak.org

Nicolas Cellier
Now http://build.squeak.org/job/SqueakTrunk/856/ is back to a better red state: one that time out after 20 minutes because of the [Warning signal: 'About to serialize an empty package.']
(like I told in my first mail and like in builds http://build.squeak.org/job/SqueakTrunk/823/ to http://build.squeak.org/job/SqueakTrunk/833/)

So applying Chris' fix and repairing the update-stream was not enough to get rid of it.

The Warning is triggered by #testMcdSerialization
It appears that (self mockDiffyVersion) has no changes...
Though, mockDiffyVersion tries to  change: #a toReturn: 'a2'.
Something in this test is not working as intended, but here I'll stop for tonight.


2014-05-25 0:48 GMT+02:00 Nicolas Cellier <[hidden email]>:
OK, build.squeak.org, I have to admit, you win... http://build.squeak.org/job/SqueakTrunk/855/console
Ddin't we see this failure already?

Segmentation fault Sun May 25 00:39:10 2014 Squeak VM version: 4.0-2776 #1 Thu Aug 22 10:35:56 PDT 2013 gcc 4.1.2 [Production ITHB VM] Built from: CoInterpreter VMMaker.oscog-eem.331 uuid: 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013 With: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid: 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013 Revision: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Build host: Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686 i686 i386 GNU/Linux plugin path: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776 [default: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/lib/squeak/4.0-2776/] C stack backtrace: /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d051] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d228] [0xf57fe40c] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x80e5a59] [0x473c7848] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(interpret+0x1eb)[0x808107b] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(main+0x397)[0x805d717] /lib/i686/nosegneg/libc.so.6(__libc_start_main+0xe6)[0xb7560ca6] /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805b101] Smalltalk stack dump: 0xbfa178a4 M LargePositiveInteger>\\ 0x4899127c: a(n) LargePositiveInteger


2014-05-25 0:06 GMT+02:00 Nicolas Cellier <[hidden email]>:

Ah, no, the build is still failing!
Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem with:
MCClassDefinition>>createClass
I encountered this one while updating some of my old trunk images.
The definition changed in Monticello-cwp.589:
+                       inEnvironment: (CurrentEnvironment signal ifNil: [superClass environment])
-                       inEnvironment: (EnvironmentRequest signal ifNil: [superClass environment])

But there is no EnvironmentRequest anymore when loading this definition, so we signal nil, and the load fails.
We would have expected this, it's just be renamed in:

Environments-cwp.47
Time: 22 March 2014, 7:53:17.666 pm
Rename EnvironmentRequest to CurrentEnvironment and use it to implement Environment class>>current.

To be safe, the rename should have been performed in two stages:
1) create the new class and migrate customers from the old to the new one.
2) remove the old one
It would thus have required two updates.mcm and not a single one
(MC lacks a semantic #rename: so it does not work like in-image-tools)
Unfortunately, update-cwp.48 did perform the two operations at once...

Curiously, if I take an artefact from build server and update, the upgrade is then processing fine... Don't ask why.
Since no one complained, I told to myself that it was me not following the standard process, I patched my images manually and restarted the upgrade.
But I now see that it's not just me, there is a CI machine too using Squeak trunk (anyone else???)

I have to cheat again with mcm surgery:
- publish an Environments-nice.47 that adds the CurrentEnvironment, but not removes EnvironmentRequest
- patch update-cwp.48 to point to Environments-nice.47 rather than Environments-cwp.47
That'll be in a few minutes...


2014-05-24 22:58 GMT+02:00 Nicolas Cellier <[hidden email]>:


2014-05-24 22:36 GMT+02:00 Nicolas Cellier <[hidden email]>:

Hi,
it seems that most of the builds are red for 2 months.
I checked the last artefact for squeak trunk:
http://build.squeak.org/job/SqueakTrunk/853/

It's still blocked with the [Warning signal: 'About to serialize an empty package.']
With this warning, a test never time out (I don't know why exactly, but it seems that theProcess monitored by the timeout watchdog is already suspended by the Warning)
As a result, the tests do never complete and are aborted after 20 minutes...

Chris has fixed the problem since, but it seems that the CI does not upload latest trunk.
Why?
It seems to be the same problem as the TestRunner: updating triggers the same [Warning signal: 'About to serialize an empty package.']
Ah Chris, it's irony that it's you who precisely keep on fighting modal UI ;)

Now the question: how do we escape from this situation?
Shall I cheat and modify the update that is blocking?


So I decided to cheat:
I brought update-eem.279 to the surgery block and reverted CommandLine-fbs.3 -> CommandLine-fbs.2
CommandLine-fbs.3 tried to be smart and workaround the Warning problem, but before it had a chance to load, it precisely triggered this Warning!!!
Since this update is also bringing Chris fix, let's defer CommandLine-fbs.3 to next update (eem-280) and cross fingers...






Reply | Threaded
Open this post in threaded view
|

Re: What's up on build.squeak.org

Chris Muller-3
Hi, thanks for noticing and investigating this!  Seeing this now, I
think we should signal an Error rather than a Warning to be more
TestCase friendly but also because persisting empty packages is so
painful, it should be an error, hands down.  Better to force a
resolution to the issue than silently persist modules of
future-pain...

On Sat, May 24, 2014 at 6:13 PM, Nicolas Cellier
<[hidden email]> wrote:

> Now http://build.squeak.org/job/SqueakTrunk/856/ is back to a better red
> state: one that time out after 20 minutes because of the [Warning signal:
> 'About to serialize an empty package.']
> (like I told in my first mail and like in builds
> http://build.squeak.org/job/SqueakTrunk/823/ to
> http://build.squeak.org/job/SqueakTrunk/833/)
>
> So applying Chris' fix and repairing the update-stream was not enough to get
> rid of it.
>
> The Warning is triggered by #testMcdSerialization
> It appears that (self mockDiffyVersion) has no changes...
> Though, mockDiffyVersion tries to  change: #a toReturn: 'a2'.
> Something in this test is not working as intended, but here I'll stop for
> tonight.
>
>
> 2014-05-25 0:48 GMT+02:00 Nicolas Cellier
> <[hidden email]>:
>
>> OK, build.squeak.org, I have to admit, you win...
>> http://build.squeak.org/job/SqueakTrunk/855/console
>>
>>
>> Ddin't we see this failure already?
>>
>>
>> Segmentation fault Sun May 25 00:39:10 2014
>>
>>
>> Squeak VM version: 4.0-2776 #1 Thu Aug 22 10:35:56 PDT 2013 gcc 4.1.2
>> [Production ITHB VM]
>> Built from: CoInterpreter VMMaker.oscog-eem.331 uuid:
>> 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013
>> With: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid:
>> 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013
>> Revision: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog
>> Plugins: r2545
>> http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
>> Build host: Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST
>> 2009 i686 i686 i386 GNU/Linux
>> plugin path:
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776
>> [default:
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/lib/squeak/4.0-2776/]
>>
>>
>> C stack backtrace:
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d051]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d228]
>> [0xf57fe40c]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x80e5a59]
>> [0x473c7848]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(interpret+0x1eb)[0x808107b]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(main+0x397)[0x805d717]
>> /lib/i686/nosegneg/libc.so.6(__libc_start_main+0xe6)[0xb7560ca6]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805b101]
>>
>>
>> Smalltalk stack dump:
>> 0xbfa178a4 M LargePositiveInteger>\\ 0x4899127c: a(n) LargePositiveInteger
>>
>>
>>
>> 2014-05-25 0:06 GMT+02:00 Nicolas Cellier
>> <[hidden email]>:
>>
>>> Ah, no, the build is still failing!
>>> Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem
>>> with:
>>>
>>> MCClassDefinition>>createClass
>>>
>>> I encountered this one while updating some of my old trunk images.
>>> The definition changed in Monticello-cwp.589:
>>> +                       inEnvironment: (CurrentEnvironment signal ifNil:
>>> [superClass environment])
>>> -                       inEnvironment: (EnvironmentRequest signal ifNil:
>>> [superClass environment])
>>>
>>> But there is no EnvironmentRequest anymore when loading this definition,
>>> so we signal nil, and the load fails.
>>> We would have expected this, it's just be renamed in:
>>>
>>> Environments-cwp.47
>>> Time: 22 March 2014, 7:53:17.666 pm
>>> Rename EnvironmentRequest to CurrentEnvironment and use it to implement
>>> Environment class>>current.
>>>
>>> To be safe, the rename should have been performed in two stages:
>>> 1) create the new class and migrate customers from the old to the new
>>> one.
>>> 2) remove the old one
>>> It would thus have required two updates.mcm and not a single one
>>> (MC lacks a semantic #rename: so it does not work like in-image-tools)
>>> Unfortunately, update-cwp.48 did perform the two operations at once...
>>>
>>> Curiously, if I take an artefact from build server and update, the
>>> upgrade is then processing fine... Don't ask why.
>>> Since no one complained, I told to myself that it was me not following
>>> the standard process, I patched my images manually and restarted the
>>> upgrade.
>>> But I now see that it's not just me, there is a CI machine too using
>>> Squeak trunk (anyone else???)
>>>
>>> I have to cheat again with mcm surgery:
>>> - publish an Environments-nice.47 that adds the CurrentEnvironment, but
>>> not removes EnvironmentRequest
>>> - patch update-cwp.48 to point to Environments-nice.47 rather than
>>> Environments-cwp.47
>>> That'll be in a few minutes...
>>>
>>>
>>> 2014-05-24 22:58 GMT+02:00 Nicolas Cellier
>>> <[hidden email]>:
>>>
>>>>
>>>> 2014-05-24 22:36 GMT+02:00 Nicolas Cellier
>>>> <[hidden email]>:
>>>>
>>>>> Hi,
>>>>> it seems that most of the builds are red for 2 months.
>>>>> I checked the last artefact for squeak trunk:
>>>>> http://build.squeak.org/job/SqueakTrunk/853/
>>>>>
>>>>> It's still blocked with the [Warning signal: 'About to serialize an
>>>>> empty package.']
>>>>> With this warning, a test never time out (I don't know why exactly, but
>>>>> it seems that theProcess monitored by the timeout watchdog is already
>>>>> suspended by the Warning)
>>>>> As a result, the tests do never complete and are aborted after 20
>>>>> minutes...
>>>>>
>>>>> Chris has fixed the problem since, but it seems that the CI does not
>>>>> upload latest trunk.
>>>>> Why?
>>>>> It seems to be the same problem as the TestRunner: updating triggers
>>>>> the same [Warning signal: 'About to serialize an empty package.']
>>>>> Ah Chris, it's irony that it's you who precisely keep on fighting modal
>>>>> UI ;)
>>>>>
>>>>> Now the question: how do we escape from this situation?
>>>>> Shall I cheat and modify the update that is blocking?
>>>>>
>>>>>
>>>> So I decided to cheat:
>>>> I brought update-eem.279 to the surgery block and reverted
>>>> CommandLine-fbs.3 -> CommandLine-fbs.2
>>>> CommandLine-fbs.3 tried to be smart and workaround the Warning problem,
>>>> but before it had a chance to load, it precisely triggered this Warning!!!
>>>> Since this update is also bringing Chris fix, let's defer
>>>> CommandLine-fbs.3 to next update (eem-280) and cross fingers...
>>>>
>>>
>>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: What's up on build.squeak.org

Nicolas Cellier

2014-05-25 2:39 GMT+02:00 Chris Muller <[hidden email]>:
Hi, thanks for noticing and investigating this!  Seeing this now, I
think we should signal an Error rather than a Warning to be more
TestCase friendly but also because persisting empty packages is so
painful, it should be an error, hands down.  Better to force a
resolution to the issue than silently persist modules of
future-pain...


In any case, I think you accidently uncovered bugs in Tests-Monticello.
I'm looking at a fix for a few hours, and it's really messy.
 
On Sat, May 24, 2014 at 6:13 PM, Nicolas Cellier
<[hidden email]> wrote:
> Now http://build.squeak.org/job/SqueakTrunk/856/ is back to a better red
> state: one that time out after 20 minutes because of the [Warning signal:
> 'About to serialize an empty package.']
> (like I told in my first mail and like in builds
> http://build.squeak.org/job/SqueakTrunk/823/ to
> http://build.squeak.org/job/SqueakTrunk/833/)
>
> So applying Chris' fix and repairing the update-stream was not enough to get
> rid of it.
>
> The Warning is triggered by #testMcdSerialization
> It appears that (self mockDiffyVersion) has no changes...
> Though, mockDiffyVersion tries to  change: #a toReturn: 'a2'.
> Something in this test is not working as intended, but here I'll stop for
> tonight.
>
>
> 2014-05-25 0:48 GMT+02:00 Nicolas Cellier
> <[hidden email]>:
>
>> OK, build.squeak.org, I have to admit, you win...
>> http://build.squeak.org/job/SqueakTrunk/855/console
>>
>>
>> Ddin't we see this failure already?
>>
>>
>> Segmentation fault Sun May 25 00:39:10 2014
>>
>>
>> Squeak VM version: 4.0-2776 #1 Thu Aug 22 10:35:56 PDT 2013 gcc 4.1.2
>> [Production ITHB VM]
>> Built from: CoInterpreter VMMaker.oscog-eem.331 uuid:
>> 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013
>> With: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid:
>> 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013
>> Revision: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog
>> Plugins: r2545
>> http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
>> Build host: Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST
>> 2009 i686 i686 i386 GNU/Linux
>> plugin path:
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776
>> [default:
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/lib/squeak/4.0-2776/]
>>
>>
>> C stack backtrace:
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d051]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d228]
>> [0xf57fe40c]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x80e5a59]
>> [0x473c7848]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(interpret+0x1eb)[0x808107b]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(main+0x397)[0x805d717]
>> /lib/i686/nosegneg/libc.so.6(__libc_start_main+0xe6)[0xb7560ca6]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805b101]
>>
>>
>> Smalltalk stack dump:
>> 0xbfa178a4 M LargePositiveInteger>\\ 0x4899127c: a(n) LargePositiveInteger
>>
>>
>>
>> 2014-05-25 0:06 GMT+02:00 Nicolas Cellier
>> <[hidden email]>:
>>
>>> Ah, no, the build is still failing!
>>> Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem
>>> with:
>>>
>>> MCClassDefinition>>createClass
>>>
>>> I encountered this one while updating some of my old trunk images.
>>> The definition changed in Monticello-cwp.589:
>>> +                       inEnvironment: (CurrentEnvironment signal ifNil:
>>> [superClass environment])
>>> -                       inEnvironment: (EnvironmentRequest signal ifNil:
>>> [superClass environment])
>>>
>>> But there is no EnvironmentRequest anymore when loading this definition,
>>> so we signal nil, and the load fails.
>>> We would have expected this, it's just be renamed in:
>>>
>>> Environments-cwp.47
>>> Time: 22 March 2014, 7:53:17.666 pm
>>> Rename EnvironmentRequest to CurrentEnvironment and use it to implement
>>> Environment class>>current.
>>>
>>> To be safe, the rename should have been performed in two stages:
>>> 1) create the new class and migrate customers from the old to the new
>>> one.
>>> 2) remove the old one
>>> It would thus have required two updates.mcm and not a single one
>>> (MC lacks a semantic #rename: so it does not work like in-image-tools)
>>> Unfortunately, update-cwp.48 did perform the two operations at once...
>>>
>>> Curiously, if I take an artefact from build server and update, the
>>> upgrade is then processing fine... Don't ask why.
>>> Since no one complained, I told to myself that it was me not following
>>> the standard process, I patched my images manually and restarted the
>>> upgrade.
>>> But I now see that it's not just me, there is a CI machine too using
>>> Squeak trunk (anyone else???)
>>>
>>> I have to cheat again with mcm surgery:
>>> - publish an Environments-nice.47 that adds the CurrentEnvironment, but
>>> not removes EnvironmentRequest
>>> - patch update-cwp.48 to point to Environments-nice.47 rather than
>>> Environments-cwp.47
>>> That'll be in a few minutes...
>>>
>>>
>>> 2014-05-24 22:58 GMT+02:00 Nicolas Cellier
>>> <[hidden email]>:
>>>
>>>>
>>>> 2014-05-24 22:36 GMT+02:00 Nicolas Cellier
>>>> <[hidden email]>:
>>>>
>>>>> Hi,
>>>>> it seems that most of the builds are red for 2 months.
>>>>> I checked the last artefact for squeak trunk:
>>>>> http://build.squeak.org/job/SqueakTrunk/853/
>>>>>
>>>>> It's still blocked with the [Warning signal: 'About to serialize an
>>>>> empty package.']
>>>>> With this warning, a test never time out (I don't know why exactly, but
>>>>> it seems that theProcess monitored by the timeout watchdog is already
>>>>> suspended by the Warning)
>>>>> As a result, the tests do never complete and are aborted after 20
>>>>> minutes...
>>>>>
>>>>> Chris has fixed the problem since, but it seems that the CI does not
>>>>> upload latest trunk.
>>>>> Why?
>>>>> It seems to be the same problem as the TestRunner: updating triggers
>>>>> the same [Warning signal: 'About to serialize an empty package.']
>>>>> Ah Chris, it's irony that it's you who precisely keep on fighting modal
>>>>> UI ;)
>>>>>
>>>>> Now the question: how do we escape from this situation?
>>>>> Shall I cheat and modify the update that is blocking?
>>>>>
>>>>>
>>>> So I decided to cheat:
>>>> I brought update-eem.279 to the surgery block and reverted
>>>> CommandLine-fbs.3 -> CommandLine-fbs.2
>>>> CommandLine-fbs.3 tried to be smart and workaround the Warning problem,
>>>> but before it had a chance to load, it precisely triggered this Warning!!!
>>>> Since this update is also bringing Chris fix, let's defer
>>>> CommandLine-fbs.3 to next update (eem-280) and cross fingers...
>>>>
>>>
>>
>
>
>
>




Reply | Threaded
Open this post in threaded view
|

A UTC based implementation of DateAndTime

David T. Lewis
I have been working on a variation of class DateAndTime that replaces its
instance variables (seconds offset jdn nanos) with two instance variables,
utcMicroseconds to represent microseconds elapsed since the Posix epoch, and
localOffsetSeconds to represent the local time zone offset. When instantiating
the time now, A single call primitiveUtcWithOffset is used to obtain these
two values atomically as reported by the underlying platform.

There are several advantages to this representation of DateAndTime, the most
important of which is that its magnitude is unambiguous regardless of daylight
savings transitions in local time zones.

This is my attempt to address some historical baggage in Squeak. The VM
reports time related to the local time zone, and the image attempts to
convert to UTC (sometimes incorrectly). A UTC based representation makes the
implementation of time zone tables more straightforward (see for example
the Olson time zone tables in TimeZoneDatabase on SqueakMap).

I am attaching the source code as a SAR file that can be loaded into a fully
updated Squeak trunk image. The conversion process is slow, so be patient
if you load it.

This can be run on either an intepreter VM or Cog, but if you use Cog, please
use a version dated June 2013 or later (the VM in the Squeak 4.5 all-in-one
is fine).

I am also attaching a copy of LXTestDateAndTimePerformance, which can be
used to compare the performance of some basic DateAndTime functions.

Performance of the UTC based DateAndTime is generally favorable compared to
the original. Here is what I see on my system (smaller numbers are better).

LXTestDateAndTimePerformance test results using the original Squeak DateAndTime
on an interpreter VM:
{
        #testNow->10143 .
        #testEquals->30986 .
        #testGreaterThan->80199 .
        #testLessThan->75912 .
        #testPrintString->10429 .
        #testStringAsDateAndTime->44657
}

LXTestDateAndTimePerformance test results using the new UTC based DateAndTime
on an interpreter VM:
{
        #testNow->6423 .
        #testEquals->31625 .
        #testGreaterThan->22999 .
        #testLessThan->18514 .
        #testPrintString->12502 .
        #testStringAsDateAndTime->32912
}

(CC to Brent Pinkney, author of the excellent Squeak Chronology package)

Dave




UtcDateAndTime-dtl.sar (40K) Download Attachment
LXTestDateAndTimePerformance.st (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Please use new threads for new threads. :) (was "A UTC based implementation of DateAndTime" inside "What's up on build.squeak.org")

ccrraaiigg

Hoi David--

     Cool! But please use a new thread when starting a new thread on the
mailing list? I kill threads when I'm no longer interested in them, and
don't want to miss out on stuff which is actually new.


     thanks,

-C

--
Craig Latta
www.netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: What's up on build.squeak.org

Nicolas Cellier
In reply to this post by Nicolas Cellier

2014-05-25 18:34 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-05-25 2:39 GMT+02:00 Chris Muller <[hidden email]>:

Hi, thanks for noticing and investigating this!  Seeing this now, I
think we should signal an Error rather than a Warning to be more
TestCase friendly but also because persisting empty packages is so
painful, it should be an error, hands down.  Better to force a
resolution to the issue than silently persist modules of
future-pain...


In any case, I think you accidently uncovered bugs in Tests-Monticello.
I'm looking at a fix for a few hours, and it's really messy.
 

Hooray! After publishing Tests-nice.297 there is now a trunk CI job that finished
http://build.squeak.org/job/SqueakTrunk/857/

Now we can see we have some regressions...
How could we live without CI before?

Of course, for dissecting which change introduced which regression after a 2 month interrupt, that's going to be more pain than necessary...


On Sat, May 24, 2014 at 6:13 PM, Nicolas Cellier
<[hidden email]> wrote:
> Now http://build.squeak.org/job/SqueakTrunk/856/ is back to a better red
> state: one that time out after 20 minutes because of the [Warning signal:
> 'About to serialize an empty package.']
> (like I told in my first mail and like in builds
> http://build.squeak.org/job/SqueakTrunk/823/ to
> http://build.squeak.org/job/SqueakTrunk/833/)
>
> So applying Chris' fix and repairing the update-stream was not enough to get
> rid of it.
>
> The Warning is triggered by #testMcdSerialization
> It appears that (self mockDiffyVersion) has no changes...
> Though, mockDiffyVersion tries to  change: #a toReturn: 'a2'.
> Something in this test is not working as intended, but here I'll stop for
> tonight.
>
>
> 2014-05-25 0:48 GMT+02:00 Nicolas Cellier
> <[hidden email]>:
>
>> OK, build.squeak.org, I have to admit, you win...
>> http://build.squeak.org/job/SqueakTrunk/855/console
>>
>>
>> Ddin't we see this failure already?
>>
>>
>> Segmentation fault Sun May 25 00:39:10 2014
>>
>>
>> Squeak VM version: 4.0-2776 #1 Thu Aug 22 10:35:56 PDT 2013 gcc 4.1.2
>> [Production ITHB VM]
>> Built from: CoInterpreter VMMaker.oscog-eem.331 uuid:
>> 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013
>> With: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid:
>> 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013
>> Revision: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog
>> Plugins: r2545
>> http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
>> Build host: Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST
>> 2009 i686 i686 i386 GNU/Linux
>> plugin path:
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776
>> [default:
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/lib/squeak/4.0-2776/]
>>
>>
>> C stack backtrace:
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d051]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805d228]
>> [0xf57fe40c]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x80e5a59]
>> [0x473c7848]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(interpret+0x1eb)[0x808107b]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak(main+0x397)[0x805d717]
>> /lib/i686/nosegneg/libc.so.6(__libc_start_main+0xe6)[0xb7560ca6]
>>
>> /var/lib/jenkins/workspace/SqueakTrunk/target/cog.r2776/coglinux/bin/../lib/squeak/4.0-2776/squeak[0x805b101]
>>
>>
>> Smalltalk stack dump:
>> 0xbfa178a4 M LargePositiveInteger>\\ 0x4899127c: a(n) LargePositiveInteger
>>
>>
>>
>> 2014-05-25 0:06 GMT+02:00 Nicolas Cellier
>> <[hidden email]>:
>>
>>> Ah, no, the build is still failing!
>>> Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem
>>> with:
>>>
>>> MCClassDefinition>>createClass
>>>
>>> I encountered this one while updating some of my old trunk images.
>>> The definition changed in Monticello-cwp.589:
>>> +                       inEnvironment: (CurrentEnvironment signal ifNil:
>>> [superClass environment])
>>> -                       inEnvironment: (EnvironmentRequest signal ifNil:
>>> [superClass environment])
>>>
>>> But there is no EnvironmentRequest anymore when loading this definition,
>>> so we signal nil, and the load fails.
>>> We would have expected this, it's just be renamed in:
>>>
>>> Environments-cwp.47
>>> Time: 22 March 2014, 7:53:17.666 pm
>>> Rename EnvironmentRequest to CurrentEnvironment and use it to implement
>>> Environment class>>current.
>>>
>>> To be safe, the rename should have been performed in two stages:
>>> 1) create the new class and migrate customers from the old to the new
>>> one.
>>> 2) remove the old one
>>> It would thus have required two updates.mcm and not a single one
>>> (MC lacks a semantic #rename: so it does not work like in-image-tools)
>>> Unfortunately, update-cwp.48 did perform the two operations at once...
>>>
>>> Curiously, if I take an artefact from build server and update, the
>>> upgrade is then processing fine... Don't ask why.
>>> Since no one complained, I told to myself that it was me not following
>>> the standard process, I patched my images manually and restarted the
>>> upgrade.
>>> But I now see that it's not just me, there is a CI machine too using
>>> Squeak trunk (anyone else???)
>>>
>>> I have to cheat again with mcm surgery:
>>> - publish an Environments-nice.47 that adds the CurrentEnvironment, but
>>> not removes EnvironmentRequest
>>> - patch update-cwp.48 to point to Environments-nice.47 rather than
>>> Environments-cwp.47
>>> That'll be in a few minutes...
>>>
>>>
>>> 2014-05-24 22:58 GMT+02:00 Nicolas Cellier
>>> <[hidden email]>:
>>>
>>>>
>>>> 2014-05-24 22:36 GMT+02:00 Nicolas Cellier
>>>> <[hidden email]>:
>>>>
>>>>> Hi,
>>>>> it seems that most of the builds are red for 2 months.
>>>>> I checked the last artefact for squeak trunk:
>>>>> http://build.squeak.org/job/SqueakTrunk/853/
>>>>>
>>>>> It's still blocked with the [Warning signal: 'About to serialize an
>>>>> empty package.']
>>>>> With this warning, a test never time out (I don't know why exactly, but
>>>>> it seems that theProcess monitored by the timeout watchdog is already
>>>>> suspended by the Warning)
>>>>> As a result, the tests do never complete and are aborted after 20
>>>>> minutes...
>>>>>
>>>>> Chris has fixed the problem since, but it seems that the CI does not
>>>>> upload latest trunk.
>>>>> Why?
>>>>> It seems to be the same problem as the TestRunner: updating triggers
>>>>> the same [Warning signal: 'About to serialize an empty package.']
>>>>> Ah Chris, it's irony that it's you who precisely keep on fighting modal
>>>>> UI ;)
>>>>>
>>>>> Now the question: how do we escape from this situation?
>>>>> Shall I cheat and modify the update that is blocking?
>>>>>
>>>>>
>>>> So I decided to cheat:
>>>> I brought update-eem.279 to the surgery block and reverted
>>>> CommandLine-fbs.3 -> CommandLine-fbs.2
>>>> CommandLine-fbs.3 tried to be smart and workaround the Warning problem,
>>>> but before it had a chance to load, it precisely triggered this Warning!!!
>>>> Since this update is also bringing Chris fix, let's defer
>>>> CommandLine-fbs.3 to next update (eem-280) and cross fingers...
>>>>
>>>
>>
>
>
>
>





Reply | Threaded
Open this post in threaded view
|

Re: What's up on build.squeak.org

Tobias Pape

On 25.05.2014, at 22:43, Nicolas Cellier <[hidden email]> wrote:

>
> 2014-05-25 18:34 GMT+02:00 Nicolas Cellier <[hidden email]>:
>
> 2014-05-25 2:39 GMT+02:00 Chris Muller <[hidden email]>:
>
> Hi, thanks for noticing and investigating this!  Seeing this now, I
> think we should signal an Error rather than a Warning to be more
> TestCase friendly but also because persisting empty packages is so
> painful, it should be an error, hands down.  Better to force a
> resolution to the issue than silently persist modules of
> future-pain...
>
>
> In any case, I think you accidently uncovered bugs in Tests-Monticello.
> I'm looking at a fix for a few hours, and it's really messy.
>  
>
> Hooray! After publishing Tests-nice.297 there is now a trunk CI job that finished
> http://build.squeak.org/job/SqueakTrunk/857/
>
> Now we can see we have some regressions...
> How could we live without CI before?
>
> Of course, for dissecting which change introduced which regression after a 2 month interrupt, that's going to be more pain than necessary...
>
To not make that happen again, can we make the jenkins mail squeak-dev on
important (read me, not all) information?
Like:
        more tests fail
        errors
        (possibly one nightly information)

best
        -tobias




signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Please use new threads for new threads. :) (was "A UTC based implementation of DateAndTime" inside "What's up on build.squeak.org")

Chris Muller-3
In reply to this post by ccrraaiigg
Hi Craig, you've mentioned this a few times, and sometimes I wondered
if I was doing it right.  Could you please confirm?

You're asking if one is replying to a email, but changing the
subject-matter of that conversation, then please change the
Subject-line of the email.  And, optionally(?), put the old subject
line inside parentheses prefiexed by "was:").

The purpose of this convention is to let emails be well-formed; their
subjects matching the bodies and not wandering into other subjects.
This would be helpful for searching email later too..



On Sun, May 25, 2014 at 3:04 PM, Craig Latta <[hidden email]> wrote:

>
> Hoi David--
>
>      Cool! But please use a new thread when starting a new thread on the
> mailing list? I kill threads when I'm no longer interested in them, and
> don't want to miss out on stuff which is actually new.
>
>
>      thanks,
>
> -C
>
> --
> Craig Latta
> www.netjam.org
> +31 6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Please use new threads for new threads. :) (was "A UTC based implementation of DateAndTime" inside "What's up on build.squeak.org")

David T. Lewis
In reply to this post by ccrraaiigg
On Sun, May 25, 2014 at 10:04:22PM +0200, Craig Latta wrote:
>
> Hoi David--
>
>      Cool! But please use a new thread when starting a new thread on the
> mailing list? I kill threads when I'm no longer interested in them, and
> don't want to miss out on stuff which is actually new.
>

I apologize, I didn't realized that I was messing up the mail threads. I'll
take care not to do that in the future.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: Please use new threads for new threads. :) (was "A UTC based implementation of DateAndTime" inside "What's up on build.squeak.org")

David T. Lewis
In reply to this post by Chris Muller-3
On Sun, May 25, 2014 at 05:40:10PM -0500, Chris Muller wrote:

>
> On Sun, May 25, 2014 at 3:04 PM, Craig Latta <[hidden email]> wrote:
> >
> > Hoi David--
> >
> >      Cool! But please use a new thread when starting a new thread on the
> > mailing list? I kill threads when I'm no longer interested in them, and
> > don't want to miss out on stuff which is actually new.
> >
>
> Hi Craig, you've mentioned this a few times, and sometimes I wondered
> if I was doing it right.  Could you please confirm?
>
> You're asking if one is replying to a email, but changing the
> subject-matter of that conversation, then please change the
> Subject-line of the email.  And, optionally(?), put the old subject
> line inside parentheses prefiexed by "was:").
>
> The purpose of this convention is to let emails be well-formed; their
> subjects matching the bodies and not wandering into other subjects.
> This would be helpful for searching email later too..
>

Hi Chris,

In this case, I think that caused a problem for a different reason. Out of
convenience (and this is something I will not do again), I sometimes start
a new mail message by "replying" to an old one, then changing to my new
subject line. I had assumed (without ever bothering to check) that mail threading
is done based on subject line, and had not noticed that the mail headers
contain the "In-Reply-To:" information that no doubt is used for connecting
the mail threads.

So in the future I will not use "reply to" unless actually replying to something.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: Please use new threads for new threads. :) (was "A UTC based implementation of DateAndTime" inside "What's up on build.squeak.org")

Eliot Miranda-2



On Sun, May 25, 2014 at 7:34 PM, David T. Lewis <[hidden email]> wrote:
On Sun, May 25, 2014 at 05:40:10PM -0500, Chris Muller wrote:
>
> On Sun, May 25, 2014 at 3:04 PM, Craig Latta <[hidden email]> wrote:
> >
> > Hoi David--
> >
> >      Cool! But please use a new thread when starting a new thread on the
> > mailing list? I kill threads when I'm no longer interested in them, and
> > don't want to miss out on stuff which is actually new.
> >
>
> Hi Craig, you've mentioned this a few times, and sometimes I wondered
> if I was doing it right.  Could you please confirm?
>
> You're asking if one is replying to a email, but changing the
> subject-matter of that conversation, then please change the
> Subject-line of the email.  And, optionally(?), put the old subject
> line inside parentheses prefiexed by "was:").
>
> The purpose of this convention is to let emails be well-formed; their
> subjects matching the bodies and not wandering into other subjects.
> This would be helpful for searching email later too..
>

Hi Chris,

In this case, I think that caused a problem for a different reason. Out of
convenience (and this is something I will not do again), I sometimes start
a new mail message by "replying" to an old one, then changing to my new
subject line. I had assumed (without ever bothering to check) that mail threading
is done based on subject line, and had not noticed that the mail headers
contain the "In-Reply-To:" information that no doubt is used for connecting
the mail threads.

So in the future I will not use "reply to" unless actually replying to something.

Surely it is the software at fault?  If you change the subject line thats clearly starting a new thread. Something I do too.   Craig?
 
Dave

--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

re: Please use new threads for new threads. :)

ccrraaiigg
In reply to this post by David T. Lewis

> In this case, I think that caused a problem for a different reason.
> Out of convenience (and this is something I will not do again), I
> sometimes start a new mail message by "replying" to an old one, then
> changing to my new subject line. I had assumed (without ever
> bothering to check) that mail threading is done based on subject
> line, and had not noticed that the mail headers contain the
> "In-Reply-To:" information that no doubt is used for connecting the
> mail threads.

     Yes; in my case the gmane.org mail/NNTP gateway uses that to make
its references headers, and Mozilla Thunderbird uses those headers to
display and manipulate threads when I read the
gmane.comp.lang.smalltalk.squeak.general newsgroup.

> So in the future I will not use "reply to" unless actually replying
> to something.

     Thanks again!


-C

--
Craig Latta
www.netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

re: Please use new threads for new threads. :)

Eliot Miranda-2



On Sun, May 25, 2014 at 7:58 PM, Craig Latta <[hidden email]> wrote:

> In this case, I think that caused a problem for a different reason.
> Out of convenience (and this is something I will not do again), I
> sometimes start a new mail message by "replying" to an old one, then
> changing to my new subject line. I had assumed (without ever
> bothering to check) that mail threading is done based on subject
> line, and had not noticed that the mail headers contain the
> "In-Reply-To:" information that no doubt is used for connecting the
> mail threads.

     Yes; in my case the gmane.org mail/NNTP gateway uses that to make
its references headers, and Mozilla Thunderbird uses those headers to
display and manipulate threads when I read the
gmane.comp.lang.smalltalk.squeak.general newsgroup.

> So in the future I will not use "reply to" unless actually replying
> to something.

     Thanks again!

Once again the tail wags the dog.  So to do something natural like reply and change subject is outlawed because fixable software is broken?  If we continue to tolerate the broken, guess what?
 


-C

--
Craig Latta
www.netjam.org
<a href="tel:%2B31%20%20%206%202757%207177" value="+31627577177">+31 6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)





--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

re: Please use new threads for new threads.

ccrraaiigg

     Short: Yeesh, I'm deleting this thread for sure. :)

     Long:

     This matters to me, because I want to be informed while having
limited time to spend.

     Naturally, I wondered how I might fix this myself, leaving the
delicate sensibilities of my fellow raconteurs untrodden. I'm not sure
what fix would work. Sometimes a reply has nothing to do with the
message to which the responder is replying, and the subject line is
totally different. Sometimes a reply is actually a response, and the
subject line might be the same ("hyperbole is great!"), somewhat
different ("perhaps communication is better [was: 'hyperbole is
great!']"), or totally different. Using simple message ID references and
the conventions of normal conversation, without turning it into an AI
project, seems the best we can manage.

> If we continue to tolerate the broken, guess what?

     Indeed, I decided not to continue tolerating a broken social
convention, by asking a fellow human being to make a small change in
behavior. I can only imagine what I would have unleashed by mentioning
top-posting. ;)


-C

--
Craig Latta
www.netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: A UTC based implementation of DateAndTime

J. Vuletich (mail lists)
In reply to this post by David T. Lewis
Hi David, Folks,

Quoting "David T. Lewis" <[hidden email]>:

> I have been working on a variation of class DateAndTime that replaces its
> instance variables (seconds offset jdn nanos) with two instance variables,
> utcMicroseconds to represent microseconds elapsed since the Posix epoch, and
> localOffsetSeconds to represent the local time zone offset. When  
> instantiating
> the time now, A single call primitiveUtcWithOffset is used to obtain these
> two values atomically as reported by the underlying platform.
>
> There are several advantages to this representation of DateAndTime, the most
> important of which is that its magnitude is unambiguous regardless  
> of daylight
> savings transitions in local time zones.
>
> This is my attempt to address some historical baggage in Squeak. The VM
> reports time related to the local time zone, and the image attempts to
> convert to UTC (sometimes incorrectly). A UTC based representation makes the
> implementation of time zone tables more straightforward (see for example
> the Olson time zone tables in TimeZoneDatabase on SqueakMap).
> ...
> Dave

I very much support this approach. I did a bit of testing of  
<primitive: 'primitiveUtcWithOffset'> . I found that on a Mac, with  
'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] Squeak  
Cog 4.0.2776' 'Mac OS' 'intel' '1092' (from Eliot's site), the second  
element I get (time zone offset) is -140473411.

The correct value would be -10800, as answered in Windows. I could not  
test on Linux yet (could not get the vm to run in Ubuntu 14.04 64 bit  
:( ).

Any clue on what's wrong on Mac OS?

BTW, which would be the current non-Cog VMs to try?

Thanks,
Juan Vuletich
Cheers,
Juan Vuletich


Reply | Threaded
Open this post in threaded view
|

A UTC based implementation of DateAndTime

Louis LaBrunda
In reply to this post by David T. Lewis
Hi Dave,

May I respectfully ask why localOffsetSeconds (to represent the local time
zone offset) is needed?  It seems to me a UTC time is enough.  Is there
really a need for the timezone offset the instance was created in?  Does
every DateAndTime instance need to carry this offset around with it?  I
would think the offset is only needed if one wants to display a date/time
as a local value and then one could get the local offset from the VM or a
program setting the user had previously supplied regardless of where the
computer was setup to run.  I guess there might be some historic interest
as to the timezone an instances (or many instances) was created in but one
could just keep that as a separate value.

Lou

On Sun, 25 May 2014 13:48:44 -0400, "David T. Lewis" <[hidden email]>
wrote:

>I have been working on a variation of class DateAndTime that replaces its
>instance variables (seconds offset jdn nanos) with two instance variables,
>utcMicroseconds to represent microseconds elapsed since the Posix epoch, and
>localOffsetSeconds to represent the local time zone offset. When instantiating
>the time now, A single call primitiveUtcWithOffset is used to obtain these
>two values atomically as reported by the underlying platform.
>
>There are several advantages to this representation of DateAndTime, the most
>important of which is that its magnitude is unambiguous regardless of daylight
>savings transitions in local time zones.
>
>This is my attempt to address some historical baggage in Squeak. The VM
>reports time related to the local time zone, and the image attempts to
>convert to UTC (sometimes incorrectly). A UTC based representation makes the
>implementation of time zone tables more straightforward (see for example
>the Olson time zone tables in TimeZoneDatabase on SqueakMap).
>
>I am attaching the source code as a SAR file that can be loaded into a fully
>updated Squeak trunk image. The conversion process is slow, so be patient
>if you load it.
>
>This can be run on either an intepreter VM or Cog, but if you use Cog, please
>use a version dated June 2013 or later (the VM in the Squeak 4.5 all-in-one
>is fine).
>
>I am also attaching a copy of LXTestDateAndTimePerformance, which can be
>used to compare the performance of some basic DateAndTime functions.
>
>Performance of the UTC based DateAndTime is generally favorable compared to
>the original. Here is what I see on my system (smaller numbers are better).
>
>LXTestDateAndTimePerformance test results using the original Squeak DateAndTime
>on an interpreter VM:
>{
> #testNow->10143 .
> #testEquals->30986 .
> #testGreaterThan->80199 .
> #testLessThan->75912 .
> #testPrintString->10429 .
> #testStringAsDateAndTime->44657
>}
>
>LXTestDateAndTimePerformance test results using the new UTC based DateAndTime
>on an interpreter VM:
>{
> #testNow->6423 .
> #testEquals->31625 .
> #testGreaterThan->22999 .
> #testLessThan->18514 .
> #testPrintString->12502 .
> #testStringAsDateAndTime->32912
>}
>
>(CC to Brent Pinkney, author of the excellent Squeak Chronology package)
>
>Dave
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com


123