- includes cs fix and required traits fixes
- is out and I would consider it as final.
Stef
On 9/22/06, stephane ducasse stephane.ducasse@gmail.com wrote:
includes cs fix and required traits fixes
is out and I would consider it as final.
Great!
We should start to setup goals for the next 3.10 release. What is your vision?
Btw, it seems that I have solved my problems with the Morphic initialization in the RestOfSqueak package. I will publish it today.
-- Pavel
On 22 sept. 06, at 18:54, Pavel Krivanek wrote:
On 9/22/06, stephane ducasse stephane.ducasse@gmail.com wrote:
includes cs fix and required traits fixes
is out and I would consider it as final.
Great!
We should start to setup goals for the next 3.10 release. What is your vision?
;) I will try to elaborate more after I sent a postmortem analysis of this release. But in a nutshell process - MC2 - SystemEditor - more tests
Actions - Removing Etoy - fixing your override problems - Cleaning a lot of stuff - trying to use your mini image - Making sure that Sophie items can be loaded - Making sure that we can load tweak - new compiler per default ?
But I cannot do that alone
Btw, it seems that I have solved my problems with the Morphic initialization in the RestOfSqueak package. I will publish it today.
-- Pavel
On 22-Sep-06, at 6:02 AM, stephane ducasse wrote:
includes cs fix and required traits fixes
is out and I would consider it as final.
Sounds promising. Might I suggest allowing a week for possible problems before blessing it? There are few thigs quite as embarrassing as declaring a final version and finding out you forgot something crucial. DAMHIKT, as they say in the woodworking world.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- PORTE-KOCHERE - Sacramental wine
tim Rowledge wrote:
On 22-Sep-06, at 6:02 AM, stephane ducasse wrote:
includes cs fix and required traits fixes
is out and I would consider it as final.
Sounds promising. Might I suggest allowing a week for possible problems before blessing it? There are few thigs quite as embarrassing as declaring a final version and finding out you forgot something crucial. DAMHIKT, as they say in the woodworking world.
Wouldn't the VM Crash, that I and others reported, be a reason not to release until fixed? Mantis issue# 0005056
brad
Brad Fuller wrote:
tim Rowledge wrote:
On 22-Sep-06, at 6:02 AM, stephane ducasse wrote:
includes cs fix and required traits fixes
is out and I would consider it as final.
Sounds promising. Might I suggest allowing a week for possible problems before blessing it? There are few thigs quite as embarrassing as declaring a final version and finding out you forgot something crucial. DAMHIKT, as they say in the woodworking world.
Wouldn't the VM Crash, that I and others reported, be a reason not to release until fixed? Mantis issue# 0005056
brad
No comment on my question?
Hi brad
been an VM ignorant I cannot reply. Now I hope that this bug can be fixed for 3.9 VMs It seems to me that from an image perspective we can safely release the image. Now we should also move, so that people migrate their code on 3.9 and that we start on 3.10 :)
Stef
includes cs fix and required traits fixes
is out and I would consider it as final.
Sounds promising. Might I suggest allowing a week for possible problems before blessing it? There are few thigs quite as embarrassing as declaring a final version and finding out you forgot something crucial. DAMHIKT, as they say in the woodworking world.
Wouldn't the VM Crash, that I and others reported, be a reason not to release until fixed? Mantis issue# 0005056
brad
No comment on my question?
stephane ducasse wrote:
Hi brad
been an VM ignorant I cannot reply. Now I hope that this bug can be fixed for 3.9 VMs It seems to me that from an image perspective we can safely release the image. Now we should also move, so that people migrate their code on 3.9 and that we start on 3.10 :)
Thanks for your comment, Stef. That seems reasonable. However, are you sure that it's a VM issue? The VM crashes, but can it not be an issue from higher up?
brad
Stef
includes cs fix and required traits fixes
is out and I would consider it as final.
Sounds promising. Might I suggest allowing a week for possible problems before blessing it? There are few thigs quite as embarrassing as declaring a final version and finding out you forgot something crucial. DAMHIKT, as they say in the woodworking world.
Wouldn't the VM Crash, that I and others reported, be a reason not to release until fixed? Mantis issue# 0005056
brad
No comment on my question?
been an VM ignorant I cannot reply. Now I hope that this bug can be fixed for 3.9 VMs It seems to me that from an image perspective we can safely release the image. Now we should also move, so that people migrate their code on 3.9 and that we start on 3.10 :)
Thanks for your comment, Stef. That seems reasonable. However, are you sure that it's a VM issue? The VM crashes, but can it not be an issue from higher up?
Of course it can. But what can we do? do we have reproduceable bugs. I do not think so. So we can stop 3.9 and postpone it but I'm pretty sure it will not help.
VW has good VM because some smart guys are payed full time for that. Now the community does not want to understand that money (the stuff with believe has value) is a good way to make things happening. So improvements will be slow and we should leave with that. Now if every seasoned squeakers would put 100 $ on a pot we could make that change. I tried with the foundation but failed. So now I will watch (but sadly I know the answer).
Stef
stephane ducasse wrote:
been an VM ignorant I cannot reply. Now I hope that this bug can be fixed for 3.9 VMs It seems to me that from an image perspective we can safely release the image. Now we should also move, so that people migrate their code on 3.9 and that we start on 3.10 :)
Thanks for your comment, Stef. That seems reasonable. However, are you sure that it's a VM issue? The VM crashes, but can it not be an issue from higher up?
Of course it can. But what can we do? do we have reproduceable bugs. I do not think so.
The code is in the mantis defect that is 100% reproducible on my PC. I think it's easy to duplicate or make other PCs crash.
So we can stop 3.9 and postpone it but I'm pretty sure it will not help.
I think what you are saying is that 3.9 should be pushed forward because there are few people to look at this problem. If this is the case, a couple of comments to that:
* Tim's been assigned the defect. * John said he'd look at the Mac version of it. * what is the acceptance criteria for releasing a major version?
We don't know when Tim and John will be looking at the problem. But, certainly a crash should be enough to stop and consider the release. No?
Thanks to Tim and John for looking into this!
VW has good VM because some smart guys are payed full time for that. Now the community does not want to understand that money (the stuff with believe has value) is a good way to make things happening. So improvements will be slow and we should leave with that. Now if every seasoned squeakers would put 100 $ on a pot we could make that change. I tried with the foundation but failed. So now I will watch (but sadly I know the answer).
I'm a poor musician... but I could spare a C note for the cause!. ;-)
On 25-Sep-06, at 1:42 PM, Brad Fuller wrote:
stephane ducasse wrote:
been an VM ignorant I cannot reply. Now I hope that this bug can be fixed for 3.9 VMs It seems to me that from an image perspective we can safely release the image. Now we should also move, so that people migrate their code on 3.9 and that we start on 3.10 :)
Thanks for your comment, Stef. That seems reasonable. However, are you sure that it's a VM issue? The VM crashes, but can it not be an issue from higher up?
Of course it can. But what can we do? do we have reproduceable bugs. I do not think so.
The code is in the mantis defect that is 100% reproducible on my PC. I think it's easy to duplicate or make other PCs crash.
So we can stop 3.9 and postpone it but I'm pretty sure it will not help.
I think what you are saying is that 3.9 should be pushed forward because there are few people to look at this problem. If this is the case, a couple of comments to that:
It doesn't affect my G5 mac so far. I have to say, 16 million float additions in 61 mS is damn fast.
It would be helpful if someone could build a PC vm with a small change in the code that prints the callstack after a problem like this so that it doesn't cast the context address to a signed value before printing it. I'm puzzled by the apparently large jump to -2128068388 HandMorph>handleEvent: -2128068768 MouseOverHandler>processMouseOver: from 2032428416 HandMorph>handleEvent: 2032428116 HandMorph>processEvents
-2128068768 is 0x81283F60 and 2032428416 is 0x79246580; that's a bit more of a difference than the usual 92 byte increment as we build the stack sending messages. I don't see anything very odd about the code in HandMorph>handleEvent: that would lead me to expect any message sending funny business.
In the function printCallStackOf() that you should find in interp.c, try changing /* end findSelectorOfMethod:forReceiver: */; printNum(ctxt); print(" "); if (!(ctxt == home)) { to /* end findSelectorOfMethod:forReceiver: */; printf("%X", ctxt); print(" "); if (!(ctxt == home)) {
and see if it can give us the stack in hex.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Utinam coniurati te in foro interficiant! = May conspirators assassinate you in the mall!
tim Rowledge wrote:
On 25-Sep-06, at 1:42 PM, Brad Fuller wrote:
stephane ducasse wrote:
been an VM ignorant I cannot reply. Now I hope that this bug can be fixed for 3.9 VMs It seems to me that from an image perspective we can safely release the image. Now we should also move, so that people migrate their code on 3.9 and that we start on 3.10 :)
Thanks for your comment, Stef. That seems reasonable. However, are you sure that it's a VM issue? The VM crashes, but can it not be an issue from higher up?
Of course it can. But what can we do? do we have reproduceable bugs. I do not think so.
The code is in the mantis defect that is 100% reproducible on my PC. I think it's easy to duplicate or make other PCs crash.
So we can stop 3.9 and postpone it but I'm pretty sure it will not help.
I think what you are saying is that 3.9 should be pushed forward because there are few people to look at this problem. If this is the case, a couple of comments to that:
It doesn't affect my G5 mac so far. I have to say, 16 million float additions in 61 mS is damn fast.
It would be helpful if someone could build a PC vm with a small change in the code that prints the callstack after a problem like this so that it doesn't cast the context address to a signed value before printing it. I'm puzzled by the apparently large jump to -2128068388 HandMorph>handleEvent: -2128068768 MouseOverHandler>processMouseOver: from 2032428416 HandMorph>handleEvent: 2032428116 HandMorph>processEvents
-2128068768 is 0x81283F60 and 2032428416 is 0x79246580; that's a bit more of a difference than the usual 92 byte increment as we build the stack sending messages. I don't see anything very odd about the code in HandMorph>handleEvent: that would lead me to expect any message sending funny business.
In the function printCallStackOf() that you should find in interp.c, try changing /* end findSelectorOfMethod:forReceiver: */; printNum(ctxt); print(" "); if (!(ctxt == home)) { to /* end findSelectorOfMethod:forReceiver: */; printf("%X", ctxt); print(" "); if (!(ctxt == home)) {
and see if it can give us the stack in hex.
[bfuller@ives bld]$ ./squeak /home/bfuller/projects/squeak/images/Squeak3.9g-7060.image
sweep failed to find exact end of memory
813821F4 Morph>hasDropShadow 81381ABC Morph>fullDrawOn: 81381A60 Canvas>fullDraw: 81381A04 Canvas>fullDrawMorph: 81380A7C [] in Morph>drawSubmorphsOn: 813809C4 SequenceableCollection>reverseDo: 813808B0 [] in Morph>drawSubmorphsOn: 81380570 Morph>drawSubmorphsOn: 81373030 [] in Morph>fullDrawOn: 81372F1C FormCanvas>roundCornersOf:in:during: 81372DC8 Canvas>roundCornersOf:during: 8137146C Morph>fullDrawOn: 81371410 Canvas>fullDraw: 81371358 Canvas>fullDrawMorph: 813710EC [] in WorldState>drawWorld:submorphs:invalidAreasOn: 81370B94 Rectangle>allAreasOutsideList:startingAt:do: 81370A3C Rectangle>allAreasOutsideList:do: 81370FF0 [] in WorldState>drawWorld:submorphs:invalidAreasOn: 813709E0 SequenceableCollection>do: 81370A98 WorldState>drawWorld:submorphs:invalidAreasOn: 81370814 [] in WorldState>displayWorld:submorphs: 813706A4 FormCanvas>roundCornersOf:in:during: 81370648 Canvas>roundCornersOf:during: 81370534 WorldState>displayWorld:submorphs: 813703C4 PasteUpMorph>privateOuterDisplayWorld 813702D8 PasteUpMorph>displayWorld 81370420 [] in WorldState>displayWorldSafely: 8137027C BlockContext>on:do: 81370220 BlockContext>ifError: 813701C4 WorldState>displayWorldSafely: 79332CA0 WorldState>doOneCycleNowFor: 79332C44 WorldState>doOneCycleFor: 79332BE8 WorldState>doOneSubCycleFor: 79332B8C PasteUpMorph>doOneSubCycle 7932E268 MenuMorph>invokeModalAt:in:allowKeyboard: 7932E20C MenuMorph>invokeModal: 7932E09C MenuMorph>invokeModal 7932C6E0 PluggableTextMorph>yellowButtonActivity: 7932C684 TextMorphForEditView>mouseDown: 7932C628 Morph>handleMouseDown: 7932C5CC MouseButtonEvent>sentTo: 7932C570 Morph>handleEvent: 7932C508 MorphicEventDispatcher>dispatchMouseDown:with: 7932C484 MorphicEventDispatcher>dispatchEvent:with: 7932C428 Morph>processEvent:using: 7932C3A4 MorphicEventDispatcher>dispatchMouseDown:with: 7932C320 MorphicEventDispatcher>dispatchEvent:with: 7932C2C4 Morph>processEvent:using: 7932C268 MorphicEventDispatcher>dispatchMouseDown:with: 7932C20C MorphicEventDispatcher>dispatchEvent:with: 7932C1B0 Morph>processEvent:using: 7932C12C MorphicEventDispatcher>dispatchMouseDown:with: 7932C0D0 MorphicEventDispatcher>dispatchEvent:with: 7932C074 Morph>processEvent:using: 7932C018 MorphicEventDispatcher>dispatchMouseDown:with: 7932BFBC MorphicEventDispatcher>dispatchEvent:with: 7932BF50 Morph>processEvent:using: 7932BEF4 PasteUpMorph>processEvent:using: 7932BE3C Morph>processEvent: 7932BDE0 HandMorph>sendEvent:focus:clear: 7932BD84 HandMorph>sendMouseEvent: 7932BCF4 HandMorph>handleEvent: 7932BC18 HandMorph>processEvents 7932BC74 [] in WorldState>doOneCycleNowFor: 7932BBBC SequenceableCollection>do: 7932BB60 WorldState>handsDo: 7932BB04 WorldState>doOneCycleNowFor: 7932BAA8 WorldState>doOneCycleFor: 7932BA4C PasteUpMorph>doOneCycle 78F82E24 [] in >spawnNewProcess 78F82EDC [] in BlockContext>newProcess
[bfuller@ives bld]$ ./squeak -version 3.9-8 #6 Tue Sep 26 15:01:19 PDT 2006 gcc 4.1.1 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux ives 2.6.16-1.2080.16.rrt.rhfc5.ccrma #1 PREEMPT Tue Jul 25 15:06:37 EDT 2006 i686 i686 i386 GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-8/*.so
Brad Fuller wrote:
tim Rowledge wrote:
It doesn't affect my G5 mac so far. I have to say, 16 million float additions in 61 mS is damn fast.
It would be helpful if someone could build a PC vm with a small change in the code that prints the callstack after a problem like this so that it doesn't cast the context address to a signed value before printing it. I'm puzzled by the apparently large jump to -2128068388 HandMorph>handleEvent: -2128068768 MouseOverHandler>processMouseOver: from 2032428416 HandMorph>handleEvent: 2032428116 HandMorph>processEvents
-2128068768 is 0x81283F60 and 2032428416 is 0x79246580; that's a bit more of a difference than the usual 92 byte increment as we build the stack sending messages. I don't see anything very odd about the code in HandMorph>handleEvent: that would lead me to expect any message sending funny business.
In the function printCallStackOf() that you should find in interp.c, try changing /* end findSelectorOfMethod:forReceiver: */; printNum(ctxt); print(" "); if (!(ctxt == home)) { to /* end findSelectorOfMethod:forReceiver: */; printf("%X", ctxt); print(" "); if (!(ctxt == home)) {
and see if it can give us the stack in hex.
[bfuller@ives bld]$ ./squeak /home/bfuller/projects/squeak/images/Squeak3.9g-7060.image
sweep failed to find exact end of memory
813821F4 Morph>hasDropShadow 81381ABC Morph>fullDrawOn: 81381A60 Canvas>fullDraw: 81381A04 Canvas>fullDrawMorph: 81380A7C [] in Morph>drawSubmorphsOn: 813809C4 SequenceableCollection>reverseDo: 813808B0 [] in Morph>drawSubmorphsOn: 81380570 Morph>drawSubmorphsOn: 81373030 [] in Morph>fullDrawOn: 81372F1C FormCanvas>roundCornersOf:in:during: 81372DC8 Canvas>roundCornersOf:during: 8137146C Morph>fullDrawOn: 81371410 Canvas>fullDraw: 81371358 Canvas>fullDrawMorph: 813710EC [] in WorldState>drawWorld:submorphs:invalidAreasOn: 81370B94 Rectangle>allAreasOutsideList:startingAt:do: 81370A3C Rectangle>allAreasOutsideList:do: 81370FF0 [] in WorldState>drawWorld:submorphs:invalidAreasOn: 813709E0 SequenceableCollection>do: 81370A98 WorldState>drawWorld:submorphs:invalidAreasOn: 81370814 [] in WorldState>displayWorld:submorphs: 813706A4 FormCanvas>roundCornersOf:in:during: 81370648 Canvas>roundCornersOf:during: 81370534 WorldState>displayWorld:submorphs: 813703C4 PasteUpMorph>privateOuterDisplayWorld 813702D8 PasteUpMorph>displayWorld 81370420 [] in WorldState>displayWorldSafely: 8137027C BlockContext>on:do: 81370220 BlockContext>ifError: 813701C4 WorldState>displayWorldSafely: 79332CA0 WorldState>doOneCycleNowFor: 79332C44 WorldState>doOneCycleFor: 79332BE8 WorldState>doOneSubCycleFor: 79332B8C PasteUpMorph>doOneSubCycle 7932E268 MenuMorph>invokeModalAt:in:allowKeyboard: 7932E20C MenuMorph>invokeModal: 7932E09C MenuMorph>invokeModal 7932C6E0 PluggableTextMorph>yellowButtonActivity: 7932C684 TextMorphForEditView>mouseDown: 7932C628 Morph>handleMouseDown: 7932C5CC MouseButtonEvent>sentTo: 7932C570 Morph>handleEvent: 7932C508 MorphicEventDispatcher>dispatchMouseDown:with: 7932C484 MorphicEventDispatcher>dispatchEvent:with: 7932C428 Morph>processEvent:using: 7932C3A4 MorphicEventDispatcher>dispatchMouseDown:with: 7932C320 MorphicEventDispatcher>dispatchEvent:with: 7932C2C4 Morph>processEvent:using: 7932C268 MorphicEventDispatcher>dispatchMouseDown:with: 7932C20C MorphicEventDispatcher>dispatchEvent:with: 7932C1B0 Morph>processEvent:using: 7932C12C MorphicEventDispatcher>dispatchMouseDown:with: 7932C0D0 MorphicEventDispatcher>dispatchEvent:with: 7932C074 Morph>processEvent:using: 7932C018 MorphicEventDispatcher>dispatchMouseDown:with: 7932BFBC MorphicEventDispatcher>dispatchEvent:with: 7932BF50 Morph>processEvent:using: 7932BEF4 PasteUpMorph>processEvent:using: 7932BE3C Morph>processEvent: 7932BDE0 HandMorph>sendEvent:focus:clear: 7932BD84 HandMorph>sendMouseEvent: 7932BCF4 HandMorph>handleEvent: 7932BC18 HandMorph>processEvents 7932BC74 [] in WorldState>doOneCycleNowFor: 7932BBBC SequenceableCollection>do: 7932BB60 WorldState>handsDo: 7932BB04 WorldState>doOneCycleNowFor: 7932BAA8 WorldState>doOneCycleFor: 7932BA4C PasteUpMorph>doOneCycle 78F82E24 [] in >spawnNewProcess 78F82EDC [] in BlockContext>newProcess
[bfuller@ives bld]$ ./squeak -version 3.9-8 #6 Tue Sep 26 15:01:19 PDT 2006 gcc 4.1.1 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux ives 2.6.16-1.2080.16.rrt.rhfc5.ccrma #1 PREEMPT Tue Jul 25 15:06:37 EDT 2006 i686 i686 i386 GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-8/*.so
Oh... I should mention:
[bfuller@ives ~]$ free total used free shared buffers cached Mem: 515268 482032 33236 0 14556 130128 -/+ buffers/cache: 337348 177920 Swap: 1048568 104880 943688
I'm below the 2GB proposed issue.
On 26-Sep-06, at 3:11 PM, Brad Fuller wrote:
and see if it can give us the stack in hex.
[bfuller@ives bld]$ ./squeak /home/bfuller/projects/squeak/images/ Squeak3.9g-7060.image
sweep failed to find exact end of memory
813821F4 Morph>hasDropShadow 81381ABC Morph>fullDrawOn: 81381A60 Canvas>fullDraw: 81381A04 Canvas>fullDrawMorph:
Thanks Brad. That 128-and-a-bit Mb jump is definitely puzzling. That's a lot of allocations between the start of doOneCycleNowFor: and displayWorldSafely:
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Rules for Optimization: 1. Don't; 2. (for experts only) Don't Yet
Am 27.09.2006 um 01:01 schrieb tim Rowledge:
On 26-Sep-06, at 3:11 PM, Brad Fuller wrote:
and see if it can give us the stack in hex.
[bfuller@ives bld]$ ./squeak /home/bfuller/projects/squeak/images/ Squeak3.9g-7060.image
sweep failed to find exact end of memory
813821F4 Morph>hasDropShadow 81381ABC Morph>fullDrawOn: 81381A60 Canvas>fullDraw: 81381A04 Canvas>fullDrawMorph:
Thanks Brad. That 128-and-a-bit Mb jump is definitely puzzling. That's a lot of allocations between the start of doOneCycleNowFor: and displayWorldSafely:
Wasn't the test case to allocate some huge FloatArrays? Might explain the jump. And the crash, if the arrays are allocated across the 2GB border.
- Bert -
Il giorno lun, 25/09/2006 alle 13.42 -0700, Brad Fuller ha scritto:
stephane ducasse wrote:
been an VM ignorant I cannot reply. Now I hope that this bug can be fixed for 3.9 VMs It seems to me that from an image perspective we can safely release the image. Now we should also move, so that people migrate their code on 3.9 and that we start on 3.10 :)
Thanks for your comment, Stef. That seems reasonable. However, are you sure that it's a VM issue? The VM crashes, but can it not be an issue from higher up?
Of course it can. But what can we do? do we have reproduceable bugs. I do not think so.
The code is in the mantis defect that is 100% reproducible on my PC. I think it's easy to duplicate or make other PCs crash.
I can reproduce it on my system, (Fedora Core 5, 3.9-7 vm, 3.8 image).
So we can stop 3.9 and postpone it but I'm pretty sure it will not help.
I think what you are saying is that 3.9 should be pushed forward because there are few people to look at this problem. If this is the case, a couple of comments to that:
- Tim's been assigned the defect.
- John said he'd look at the Mac version of it.
- what is the acceptance criteria for releasing a major version?
We don't know when Tim and John will be looking at the problem. But, certainly a crash should be enough to stop and consider the release. No?
How common is this single bug? Can't we just add a remark in a "known problems" section, and say it will be fixed as soon as possible?
Giovanni
On 2006 September 25 17:26, Giovanni Corriga wrote:
Il giorno lun, 25/09/2006 alle 13.42 -0700, Brad Fuller ha scritto:
stephane ducasse wrote:
<<snip>>
The code is in the mantis defect that is 100% reproducible on my PC. I think it's easy to duplicate or make other PCs crash.
I can reproduce it on my system, (Fedora Core 5, 3.9-7 vm, 3.8 image).
Guys,
Could you paste the exact output of "squeak -version"? - The reason I am saying it is that this _does_ work on my SuSE 9.3. I think there are multiple 3.9-7 VMs, and we already saw significant performance difference between 3.9 VM version built on RedHat (i think) and Ian's version (on another thread this week named something like Squeak is slooow):
My VM version: $ squeak -version 3.9-7 #5 Mon Apr 24 20:07:28 PDT 2006 gcc 3.3.5 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux vps.piumarta.com 2.4.20-021stab028.18.777-enterprise #1 SMP Wed Sep 14 19:34:46 MSD 2005 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-7/*.so
| a b | a := FloatArray new: (16 * 1024*1024). b := FloatArray new: (16 * 1024*1024). [a += b] timeToRun. "runs OK in 270 ms"
So it may be completely reproducible on one system, but not all - I have no idea, but maybe the exact VM version will give some clue,
Milan
So we can stop 3.9 and postpone it but I'm pretty sure it will not help.
I think what you are saying is that 3.9 should be pushed forward because there are few people to look at this problem. If this is the case, a couple of comments to that:
- Tim's been assigned the defect.
- John said he'd look at the Mac version of it.
- what is the acceptance criteria for releasing a major version?
We don't know when Tim and John will be looking at the problem. But, certainly a crash should be enough to stop and consider the release. No?
How common is this single bug? Can't we just add a remark in a "known problems" section, and say it will be fixed as soon as possible?
Giovanni
Il giorno lun, 25/09/2006 alle 20.13 -0400, Milan Zimmermann ha scritto:
On 2006 September 25 17:26, Giovanni Corriga wrote:
Il giorno lun, 25/09/2006 alle 13.42 -0700, Brad Fuller ha scritto:
stephane ducasse wrote:
<<snip>>
The code is in the mantis defect that is 100% reproducible on my PC. I think it's easy to duplicate or make other PCs crash.
I can reproduce it on my system, (Fedora Core 5, 3.9-7 vm, 3.8 image).
Guys,
Could you paste the exact output of "squeak -version"? - The reason I am saying it is that this _does_ work on my SuSE 9.3. I think there are multiple 3.9-7 VMs, and we already saw significant performance difference between 3.9 VM version built on RedHat (i think) and Ian's version (on another thread this week named something like Squeak is slooow):
Ok, here's mine:
[gcorriga@rincewind ~]$ squeak -version 3.9-7 #1 Thu May 18 12:06:33 CEST 2006 gcc 4.1.0 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux rincewind 2.6.16-1.2111_FC5.stk16 #1 Mon May 8 10:49:23 EDT 2006 i686 i686 i386 GNU/Linux default plugin location: /usr/lib/squeak/3.9-7/*.so
could this be related to the use of gcc 4.x?
Giovanni
Am 26.09.2006 um 10:23 schrieb Giovanni Corriga:
Il giorno lun, 25/09/2006 alle 20.13 -0400, Milan Zimmermann ha scritto:
On 2006 September 25 17:26, Giovanni Corriga wrote:
Il giorno lun, 25/09/2006 alle 13.42 -0700, Brad Fuller ha scritto:
stephane ducasse wrote:
<<snip>>
The code is in the mantis defect that is 100% reproducible on my PC. I think it's easy to duplicate or make other PCs crash.
I can reproduce it on my system, (Fedora Core 5, 3.9-7 vm, 3.8 image).
Guys,
Could you paste the exact output of "squeak -version"? - The reason I am saying it is that this _does_ work on my SuSE 9.3. I think there are multiple 3.9-7 VMs, and we already saw significant performance difference between 3.9 VM version built on RedHat (i think) and Ian's version (on another thread this week named something like Squeak is slooow):
Ok, here's mine:
[gcorriga@rincewind ~]$ squeak -version 3.9-7 #1 Thu May 18 12:06:33 CEST 2006 gcc 4.1.0 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux rincewind 2.6.16-1.2111_FC5.stk16 #1 Mon May 8 10:49:23 EDT 2006 i686 i686 i386 GNU/Linux default plugin location: /usr/lib/squeak/3.9-7/*.so
could this be related to the use of gcc 4.x?
AFAIK it's not related to the Squeak binary at all but just depends on the system. The problem started to pop up only recently (a year or maybe two ago). Maybe it's kernel 2.6 related or something else that changed in Linux recently - or simply that people have more than 2 GB virtual memory nowadays.
The problem always occurs when Squeak is loaded partially around the 2 GB limit. The fix for the problem at hand would be a code audit in the FloatArray plugin, converting ints to unsigned where necessary.
- Bert -
Hi,
AFAIK it's not related to the Squeak binary at all but just depends on the system. The problem started to pop up only recently (a year or maybe two ago). Maybe it's kernel 2.6 related or something else that changed in Linux recently - or simply that people have more than 2 GB virtual memory nowadays.
The problem always occurs when Squeak is loaded partially around the 2 GB limit. The fix for the problem at hand would be a code audit in the FloatArray plugin, converting ints to unsigned where necessary.
I'm being working around this problem since months with the parrmeter:
-mmap 512M
Cheers,
-- Diego
-mmap size[mk] requests that a variable heap of at most size bytes be allocated. (The suffixes are as described for the '-memory' option.) squeak will initially allocate a heap that is large enough to hold the image, with a small amount of headroom. If at any time Squeak requires more memory for its image then additional space will be allocated dynamically. Likewise, when memory is no longer needed it will deallocated and returned to the system. The size argument places an upper limit on how big the heap can grow in this fashion. squeak uses a dynamic heap by default with the maximum size set to 75% of the available virtual memory or 1 gigabyte, whichever is smaller. -------------
In my past experiences which certainly depends on the operating system/version viewpoint, I found that on os-x setting the mmap size to 1GB gave a much higher probability that the memory mapped would start at or cross the 2GB boundary. Which is why out of the box the carbon VM is set to mmap at 512MB.
On 26-Sep-06, at 6:59 AM, Diego Gomez Deck wrote:
Hi,
AFAIK it's not related to the Squeak binary at all but just depends on the system. The problem started to pop up only recently (a year or maybe two ago). Maybe it's kernel 2.6 related or something else that changed in Linux recently - or simply that people have more than 2 GB virtual memory nowadays.
The problem always occurs when Squeak is loaded partially around the 2 GB limit. The fix for the problem at hand would be a code audit in the FloatArray plugin, converting ints to unsigned where necessary.
I'm being working around this problem since months with the parrmeter:
-mmap 512M
Cheers,
-- Diego
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On 2006 September 26 04:23, Giovanni Corriga wrote:
Ok, here's mine:
[gcorriga@rincewind ~]$ squeak -version 3.9-7 #1 Thu May 18 12:06:33 CEST 2006 gcc 4.1.0 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux rincewind 2.6.16-1.2111_FC5.stk16 #1 Mon May 8 10:49:23 EDT 2006 i686 i686 i386 GNU/Linux default plugin location: /usr/lib/squeak/3.9-7/*.so
could this be related to the use of gcc 4.x?
I think Bert said in another reply, this problem is likely due to the kernel and/or memory over 2Gb. On this system (where it works) I have 1Gb memory and something like 2Gb swap, my kernel=vmlinuz-2.6.11.4-21.13 so I guess it makes sense it works here from memory perspectivenot sure about 2.6 kernel. Giovanni, do you have over 2GB?
Milan
Giovanni
Il giorno mar, 26/09/2006 alle 09.56 -0400, Milan Zimmermann ha scritto:
On 2006 September 26 04:23, Giovanni Corriga wrote:
Ok, here's mine:
[gcorriga@rincewind ~]$ squeak -version 3.9-7 #1 Thu May 18 12:06:33 CEST 2006 gcc 4.1.0 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux rincewind 2.6.16-1.2111_FC5.stk16 #1 Mon May 8 10:49:23 EDT 2006 i686 i686 i386 GNU/Linux default plugin location: /usr/lib/squeak/3.9-7/*.so
could this be related to the use of gcc 4.x?
I think Bert said in another reply, this problem is likely due to the kernel and/or memory over 2Gb. On this system (where it works) I have 1Gb memory and something like 2Gb swap, my kernel=vmlinuz-2.6.11.4-21.13 so I guess it makes sense it works here from memory perspectivenot sure about 2.6 kernel. Giovanni, do you have over 2GB?
Actually, yes. Anyway, if the workaround suggested by Diego and confirmed by John works, we shouldn't postpone the 3.9 release: let's just add a remark in the release notes and worry about fixing the bug for either 3.9.1 or 3.10.
Giovanni
My point is simple I take responsibility for what I know I can do or try to do and I do "impose" (because noone can impose work on other) any stuff on others.
So sometimes I have argument with andreas and this is normal because we have some strong views on the world but from the VM perspective I respect the guys doing the job there. So if they do not shout and block the release then this is ok for me. Else I should be smart enough to really contribute.
Stef
On 25 sept. 06, at 22:42, Brad Fuller wrote:
stephane ducasse wrote:
been an VM ignorant I cannot reply. Now I hope that this bug can be fixed for 3.9 VMs It seems to me that from an image perspective we can safely release the image. Now we should also move, so that people migrate their code on 3.9 and that we start on 3.10 :)
Thanks for your comment, Stef. That seems reasonable. However, are you sure that it's a VM issue? The VM crashes, but can it not be an issue from higher up?
Of course it can. But what can we do? do we have reproduceable bugs. I do not think so.
The code is in the mantis defect that is 100% reproducible on my PC. I think it's easy to duplicate or make other PCs crash.
So we can stop 3.9 and postpone it but I'm pretty sure it will not help.
I think what you are saying is that 3.9 should be pushed forward because there are few people to look at this problem. If this is the case, a couple of comments to that:
- Tim's been assigned the defect.
- John said he'd look at the Mac version of it.
- what is the acceptance criteria for releasing a major version?
We don't know when Tim and John will be looking at the problem. But, certainly a crash should be enough to stop and consider the release. No?
Thanks to Tim and John for looking into this!
VW has good VM because some smart guys are payed full time for that. Now the community does not want to understand that money (the stuff with believe has value) is a good way to make things happening. So improvements will be slow and we should leave with that. Now if every seasoned squeakers would put 100 $ on a pot we could make that change. I tried with the foundation but failed. So now I will watch (but sadly I know the answer).
I'm a poor musician... but I could spare a C note for the cause!. ;-)
Well I've just downloaded this and I'm very disappointed. I appreciate how much work is involved and how many sleepless nights it must have caused Marcus and Stef but....
This simply isn't an image to release to the general public. The two Workspaces need to be edited and de-typo'd.
There are now two preferences tools, neither of which handle font settings or display setings. If one is going to replace an old tool with a new one it ought to noticeably improve upon it. And, of course, actually *replace* it.
Why is a package of omnibrowser included but not, so far as I can tell, hooked up to use? Not to mention it appears to be non- functional; on my machine (a very fast dualcore mac) I opened an OBSystemBrowser with #openOnClass: Object, pressed the 'hierarchy' button and got bored after more than a minute of waiting for a new browser.
What are Morphic-Models 39Deprecated FlexibleVocabularies-Info ScriptLoader there for?
It may be a good start but it really isn't ready to be a new release. Just pushing something out because you're bored or tired or along time has passed is not sensible. All it does is make more, nastier, work later.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim 29A, the hexadecimal of the Beast.
tim Rowledge a écrit :
Well I've just downloaded this and I'm very disappointed. I appreciate how much work is involved and how many sleepless nights it must have caused Marcus and Stef but....
This simply isn't an image to release to the general public. The two Workspaces need to be edited and de-typo'd.
There are now two preferences tools, neither of which handle font settings or display setings. If one is going to replace an old tool with a new one it ought to noticeably improve upon it. And, of course, actually *replace* it.
Why is a package of omnibrowser included but not, so far as I can tell, hooked up to use? Not to mention it appears to be non-functional; on my machine (a very fast dualcore mac) I opened an OBSystemBrowser with #openOnClass: Object, pressed the 'hierarchy' button and got bored after more than a minute of waiting for a new browser.
What are Morphic-Models 39Deprecated FlexibleVocabularies-Info ScriptLoader there for?
It may be a good start but it really isn't ready to be a new release. Just pushing something out because you're bored or tired or along time has passed is not sensible. All it does is make more, nastier, work later.
Yes you are right, this is not a polished version, but i see more this version as a good start for Squeak distributions (squeak-land, small-land, s...) who could add more bells and whisles (documentation, specific examples and tools, ...). This is not for end users. No end users download the last Linux kernel, only developpers or real hackers would like to do that.
Look for example as the excellent work of Damien with the squeak-dev image for developers here : http://damiencassou.seasidehosting.st/seaside/pier
-- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO http://purl.org/net/SergeStinckwich oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##
Hi tim
This is good that you woke up. Luckily we were not looking for your feedback earlier.! Sorry but you really pissed me off.
So if you want to fix what you think are the problems, please do. Because from my side this is done. Now if you want to do RC2 you are my guest.
Stef
On 26 sept. 06, at 01:22, tim Rowledge wrote:
Well I've just downloaded this and I'm very disappointed. I appreciate how much work is involved and how many sleepless nights it must have caused Marcus and Stef but....
This simply isn't an image to release to the general public. The two Workspaces need to be edited and de-typo'd.
There are now two preferences tools, neither of which handle font settings or display setings. If one is going to replace an old tool with a new one it ought to noticeably improve upon it. And, of course, actually *replace* it.
Why is a package of omnibrowser included but not, so far as I can tell, hooked up to use? Not to mention it appears to be non- functional; on my machine (a very fast dualcore mac) I opened an OBSystemBrowser with #openOnClass: Object, pressed the 'hierarchy' button and got bored after more than a minute of waiting for a new browser.
What are Morphic-Models 39Deprecated FlexibleVocabularies-Info ScriptLoader there for?
It may be a good start but it really isn't ready to be a new release. Just pushing something out because you're bored or tired or along time has passed is not sensible. All it does is make more, nastier, work later.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim 29A, the hexadecimal of the Beast.
On 26.09.2006, at 01:22, tim Rowledge wrote:
Well I've just downloaded this and I'm very disappointed. I appreciate how much work is involved and how many sleepless nights it must have caused Marcus and Stef but....
If those things are the one you find to be very disappointed, I take it as a compliment: The changes in 3.9 are so huge that I, honestly, am happy if these are the problems you find!
This simply isn't an image to release to the general public. The two Workspaces need to be edited and de-typo'd.
Please do.
There are now two prefer ences tools, neither of which handle font settings or display setings. If one is going to replace an old tool with a new one it ought to noticeably improve upon it. And, of course, actually *replace* it.
Please submit a patch. I once looked for some time into removing the old Preferences. Sadly the code is so bad that even removing it is *a lot* of work. The new preferences are an improvement on the old ones, so I fail to see why we should not have added them. Isn't this the old Squeak pattern of "doing nothing because something more perfect is thinkable" at work?
The new Preferences e.g. integrate the HTTP-Proxy preference. That alone makes them worth *a lot*. No code to be executed for proxy settings...
Why is a package of omnibrowser included but not, so far as I can tell, hooked up to use? Not to mention it appears to be non- functional; on my machine (a very fast dualcore mac) I opened an OBSystemBrowser with #openOnClass: Object, pressed the 'hierarchy' button and got bored after more than a minute of waiting for a new browser.
It is not default because it's new. If people start to use it more, fix bugs, integrate it a bit more, then we can remove the old one. Don't you think you would be more pissed if there would only be OB then the state now? People do use OmniBrowser, though. The way to do it is to set it as the Default Browser (see window menu of the Browser. I works quite well, but OB needs to be used a lot more before we can remove the old Browser.
What are Morphic-Models 39Deprecated FlexibleVocabularies-Info
This is a package from Connectors that was a pre-requisit for adding the squeakland changesets. I did once take the time to rename all categories (as this package makes no sense, it's a patch that Ned managed as an mcz package). But at some point it crept back in (I think the Morpic Teams big first "make morphic to packages" changes, or even maybe one of the >150 SqueakLand changesets).
Someone should have re-invested the time to move all methods from this package into the morphic packages. I didn't, you did not. So is it my fault?
Morphic-Models is an auto-generated category by some strange code that should be removed.
39Deprecated contains all methods that where deprecated in 3.9a, it's supposed to be there in 3.9 and removed in 3.10a
ScriptLoader
Scriptloader contains the machinary to update from the repository. This was how it was done in 3.9, for 3.10, I think people will again have a look at the tools that Bert did at Impara and retire Scriptloader. So why should this be removed from 3.9? Don't we want to do a 3.9.1?
Marcus
On 26-Sep-06, at 12:45 AM, Marcus Denker wrote:
On 26.09.2006, at 01:22, tim Rowledge wrote:
Well I've just downloaded this and I'm very disappointed. I appreciate how much work is involved and how many sleepless nights it must have caused Marcus and Stef but....
If those things are the one you find to be very disappointed, I take it as a compliment: The changes in 3.9 are so huge that I, honestly, am happy if these are the problems you find!
Exactly; that's how you *should* see it. You've done huge amounts of work and deserve the firm pat on the back that I would love to give you. I've done this same job many times and I know how painful it is.
This simply isn't an image to release to the general public. The two Workspaces need to be edited and de-typo'd.
Please do.
I'll give it a go as soon as I can make time.
There are now two prefer ences tools, neither of which handle font settings or display setings. If one is going to replace an old tool with a new one it ought to noticeably improve upon it. And, of course, actually *replace* it.
Please submit a patch. I once looked for some time into removing the old Preferences. Sadly the code is so bad that even removing it is *a lot* of work. The new preferences are an improvement on the old ones, so I fail to see why we should not have added them. Isn't this the old Squeak pattern of "doing nothing because something more perfect is thinkable" at work?
It can end up seeming that way. We could at least remove user confusion by simply removing the old preferences tool from easy access and thereby make it seem to disappear.
The new Preferences e.g. integrate the HTTP-Proxy preference. That alone makes them worth *a lot*. No code to be executed for proxy settings...
Good indeed. So I claim that it is worth thinking very hard about trying to make the new tool more complete before final release; we could surely remove a lot of new and recently-new user confusion by having all the settings available in a single place.
Why is a package of omnibrowser included but not, so far as I can tell, hooked up to use? Not to mention it appears to be non- functional; on my machine (a very fast dualcore mac) I opened an OBSystemBrowser with #openOnClass: Object, pressed the 'hierarchy' button and got bored after more than a minute of waiting for a new browser.
It is not default because it's new. If people start to use it more, fix bugs, integrate it a bit more, then we can remove the old one. Don't you think you would be more pissed if there would only be OB then the state now? People do use OmniBrowser, though. The way to do it is to set it as the Default Browser (see window menu of the Browser. I works quite well, but OB needs to be used a lot more before we can remove the old Browser.
OK; introducing a new browser system is all very well but if I had been able to take much part recently I would have suggested that it ought to have been kept as a package until it is at least close to being a good replacement. If it *is* to be included it really ought to be easy enough to access that there is a good chance of people trying it out. Buried in a menu that I bet a substantial fraction of people don't ever look at, named 'OBSystemBrowserAdaptor' is not going to attract a lot of testers.
What are Morphic-Models 39Deprecated FlexibleVocabularies-Info
This is a package from Connectors that was a pre-requisit for adding the squeakland changesets. I did once take the time to rename all categories (as this package makes no sense, it's a patch that Ned managed as an mcz package). But at some point it crept back in (I think the Morpic Teams big first "make morphic to packages" changes, or even maybe one of the >150 SqueakLand changesets).
Someone should have re-invested the time to move all methods from this package into the morphic packages. I didn't, you did not. So is it my fault?
No, it's our collective fault combined with the depressing reality of time pressure. But explanations don't alter the facts (unless you're a member of some religion or other) and we have to try to work with the facts as much as possible.
Morphic-Models is an auto-generated category by some strange code that should be removed.
In the image I'm looking at, the category 'Morphic-Models' includes a single class that has no methods at all, which makes me think that it ought not exist. It does however have a single instance (a MorphicModle1(2710) which is pointed to by a PasteUpMorph(1622) which seems to claim to be the world. This seems like some nasty crap left over from ancient times, maybe?
39Deprecated contains all methods that where deprecated in 3.9a, it's supposed to be there in 3.9 and removed in 3.10a
Sigh, yes, we still have that horrible class. Oh well.
ScriptLoader
Scriptloader contains the machinary to update from the repository. This was how it was done in 3.9, for 3.10, I think people will again have a look at the tools that Bert did at Impara and retire Scriptloader. So why should this be removed from 3.9?
What I forgot was to point out that at least partly it is the category names that cause potential confusion. Nit-picking I suppose but I'd suggest at least renaming to 'System-ScriptLoader', 'System- DeprecatedIn39' (and probably move the class MorphicModel1 into it), 'Tools-PreferenceBuilder', 'Tools-ReleaseBuilder', 'PackageInfo- FlexibleVocabularies' etc.
Well, that was fun; I just went through to make a changeset for you with those category changes and the changeset is empty. How nice, work lost. I'll try again and see if does it again....
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim There can never be a computer language in which you cannot write a bad program.
On 26-Sep-06, at 12:09 PM, tim Rowledge wrote:
Well, that was fun; I just went through to make a changeset for you with those category changes and the changeset is empty. How nice, work lost. I'll try again and see if does it again....
Yup, editing categories and even editing the system organisation results in no input to the changeset. Ooh, even back to 3.8-6665. What fun. And 3.7. And 3.6. Well, that's puzzling since I was pretty sure we've filed out SystemOrganization edits before now. And it doesn't even get into the changes log either. Very odd.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Hex dump: Where witches put used curses...
tim Rowledge wrote:
Yup, editing categories and even editing the system organisation results in no input to the changeset. Ooh, even back to 3.8-6665. What fun. And 3.7. And 3.6. Well, that's puzzling since I was pretty sure we've filed out SystemOrganization edits before now. And it doesn't even get into the changes log either. Very odd.
Uhm, to be honest I can't remember that to have ever worked. In those cases where we did it in the past it was an explicit doIt.
Cheers, - Andreas
On 26-Sep-06, at 12:42 PM, Andreas Raab wrote:
tim Rowledge wrote:
Yup, editing categories and even editing the system organisation results in no input to the changeset. Ooh, even back to 3.8-6665. What fun. And 3.7. And 3.6. Well, that's puzzling since I was pretty sure we've filed out SystemOrganization edits before now. And it doesn't even get into the changes log either. Very odd.
Uhm, to be honest I can't remember that to have ever worked. In those cases where we did it in the past it was an explicit doIt.
Well, you might be right. I can't help feeling that organization changes showed up in the filed out changes though; in fact I seem to remember them appearing far too often, like twice per fileout. Scanning some older .cs files I can find cases where the *class* organization has been included in the file, but no evidence to back up my suspicion. Class organizer changes do indeed still appear in the changeset.
There is a SystemOrganization>fileOut method that appears to work (although for some reason making a file 'SystemOrganization. 1.st.st' !) and maybe that was hooked up at some point.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Oblitus sum perpolire clepsydras! = I forgot to polish the clocks!
There is a SystemOrganization>fileOut method that appears to work (although for some reason making a file 'SystemOrganization. 1.st.st' !) and maybe that was hooked up at some point.
Also it is very important to properly log class renames. There is something broken in this area as well.
Lukas
may be rewriting the cs recorder based on MC2 metamodel using changenotification would be good. Now we have underneath all the necessary mechanisms.
There is a SystemOrganization>fileOut method that appears to work (although for some reason making a file 'SystemOrganization. 1.st.st' !) and maybe that was hooked up at some point.
Also it is very important to properly log class renames. There is something broken in this area as well.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Am 27.09.2006 um 07:33 schrieb Lukas Renggli:
There is a SystemOrganization>fileOut method that appears to work (although for some reason making a file 'SystemOrganization. 1.st.st' !) and maybe that was hooked up at some point.
Also it is very important to properly log class renames. There is something broken in this area as well.
... as well as when moving a method from one category to an other - if this moves a method from one package to another, only one MC package is marked dirty. Also, IIRC, renaming a method category does not trigger any notification.
- Bert -
I would be nice to have a list of the bugs that would be nice to fix.
Stef
Am 27.09.2006 um 07:33 schrieb Lukas Renggli:
There is a SystemOrganization>fileOut method that appears to work (although for some reason making a file 'SystemOrganization. 1.st.st' !) and maybe that was hooked up at some point.
Also it is very important to properly log class renames. There is something broken in this area as well.
... as well as when moving a method from one category to an other - if this moves a method from one package to another, only one MC package is marked dirty. Also, IIRC, renaming a method category does not trigger any notification.
- Bert -
On Sep 25, 2006, at 21:11 , Brad Fuller wrote:
Brad Fuller wrote:
tim Rowledge wrote:
Wouldn't the VM Crash, that I and others reported, be a reason not to release until fixed? Mantis issue# 0005056
brad
No comment on my question?
I think, the current VM issues would be a good reason to pospone the release.
Unfortunately, as it seems to me, the VM is quite poorly maintained. Probably the main reason being that the maintainers don't have enough time (or, in other words, because they are not paid to fix the problems). Another difficulty is that there are only few people that actually work on the VM (why?).
Apart from the bug you mention (http://bugs.impara.de/view.php? id=0005056) there are others. For example: - http://bugs.impara.de/view.php?id=4709 (VM blocks after memory consumtion exceeds ~120MB) - http://bugs.impara.de/view.php?id=4882 (VM lockup)
Cheers, Adrian
PS: cc to vm-dev
On 25-Sep-06, at 12:33 PM, Adrian Lienhard wrote:
On Sep 25, 2006, at 21:11 , Brad Fuller wrote:
Brad Fuller wrote:
tim Rowledge wrote:
Wouldn't the VM Crash, that I and others reported, be a reason not to release until fixed? Mantis issue# 0005056
brad
No comment on my question?
I think, the current VM issues would be a good reason to pospone the release.
Unfortunately, as it seems to me, the VM is quite poorly maintained. Probably the main reason being that the maintainers don't have enough time (or, in other words, because they are not paid to fix the problems). Another difficulty is that there are only few people that actually work on the VM (why?)
$ (or lack there of)
Apart from the bug you mention (http://bugs.impara.de/view.php? id=0005056) there are others.
a pointer to memory is an unsigned value, not a signed integer. Tim will gladly accept lots of $$ to fix that.
For example:
- http://bugs.impara.de/view.php?id=4709 (VM blocks after memory
consumtion exceeds ~120MB)
I added a note about http://minnow.cc.gatech.edu/squeak/3710, since likely the problem is hitting the wall when attempting to grow the image.
- http://bugs.impara.de/view.php?id=4882 (VM lockup)
See added notes about setVMStatsTraceMessageSendLevels: The Mac carbon VM and unix VMs all share the same code for aioPoll and socket logic. Since all the source code *is* available others are welcome to look at the logic and try to figure out what is going on.
Cheers, Adrian
PS: cc to vm-dev
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Adrian Lienhard wrote:
On Sep 25, 2006, at 21:11 , Brad Fuller wrote:
Brad Fuller wrote:
tim Rowledge wrote:
Wouldn't the VM Crash, that I and others reported, be a reason not to release until fixed? Mantis issue# 0005056
brad
No comment on my question?
I think, the current VM issues would be a good reason to pospone the release.
Unfortunately, as it seems to me, the VM is quite poorly maintained. Probably the main reason being that the maintainers don't have enough time (or, in other words, because they are not paid to fix the problems). Another difficulty is that there are only few people that actually work on the VM (why?).
Here are my excuses:
1. Linux on my system currently has a major major bug that causes my machine to be unusable for all but the most trivial tasks. linux blows donkies.
2. The current Slang > C compiler is very hackish and behaves in very counterintuitive ways, especially with regards to the VM.
3. It is very difficult to understand how the Slang compiler interacts with the system compiler so it would be very very difficult for anyone except the most elite Squeak programmer to work on it. -- One gripe I have with the current (recient?) system compiler is that it doesn't provide information about the scope of a variable (method context versus block context)
4. Because of how the current compiler works, it is impossible to get a working VM that isn't inlined and therefore doing normal code coverage/profiling becomes many times more difficult.
5. Mere mortals don't have access to the current version. Any hacker trying to get the "development" version can't (or at least couldn't last time I checked). You COULD develop based off of what's on the website or try to get the SVN source working (VERY HARD/IMPOSSIBLE -- used to be very reliable), but then you'd have to completely re-do your changes when you finally get a chance to sync with the mainline version. =(
Am 26.09.2006 um 00:28 schrieb Alan Grimes:
- Linux on my system currently has a major major bug that causes my
machine to be unusable for all but the most trivial tasks. linux blows donkies.
We know by now, and we could not care less. Please stop bitching about operating systems on Squeak lists. There are better places for that.
- The current Slang > C compiler is very hackish and behaves in very
counterintuitive ways, especially with regards to the VM.
Actually, the translation is quite straight-forward, in particular compared to similar translation projects in other languages. If there is something specific you want to know, just ask.
- It is very difficult to understand how the Slang compiler interacts
with the system compiler so it would be very very difficult for anyone except the most elite Squeak programmer to work on it. -- One gripe I have with the current (recient?) system compiler is that it doesn't provide information about the scope of a variable (method context versus block context)
What do you mean by "system compiler"? The (old) Squeak compiler? It indeed does handle block-local variables as method temps. Why is this a problem for Slang?
- Because of how the current compiler works, it is impossible to
get a working VM that isn't inlined and therefore doing normal code coverage/profiling becomes many times more difficult.
That would be a bug, I think, but it would not be high on the priority list. Would be a nice little project to clean that up I guess.
- Mere mortals don't have access to the current version. Any hacker
trying to get the "development" version can't (or at least couldn't last time I checked). You COULD develop based off of what's on the website or try to get the SVN source working (VERY HARD/IMPOSSIBLE -- used to be very reliable), but then you'd have to completely re-do your changes when you finally get a chance to sync with the mainline version. =(
Not true anymore, at least for the Unix VM. SVN head works perfectly for me.
- Bert -
Adrian Lienhard wrote:
I think, the current VM issues would be a good reason to pospone the release.
I disagree. The issue in question is nothing new and it's unlikely to be fixed any time soon. Mostly because we don't have a reliable way of recreating (and therefore debugging) the problem.
Unfortunately, as it seems to me, the VM is quite poorly maintained.
I don't think it's fair to draw this conclusion based on the sample size you are using in particular given that you don't seem understand the problem well enough to see why it's so hard to fix.
Probably the main reason being that the maintainers don't have enough time (or, in other words, because they are not paid to fix the problems). Another difficulty is that there are only few people that actually work on the VM (why?).
Because it's hard. In this case, the problem is largely that you can't debug this stuff in the simulator because the simulator still uses Squeak semantics (i.e., unlimited integer arithmetic). For example, if you have code saying "a + b < c ifTrue:[...]" then in C this may have some very odd results (depending on the types of a, b, and c, as well as their values) whereas in the simulator the result is always the same (since we don't type variables).
Apart from the bug you mention (http://bugs.impara.de/view.php?id=0005056) there are others. For example:
- http://bugs.impara.de/view.php?id=4709 (VM blocks after memory
consumtion exceeds ~120MB)
John has answered that one already. There is a simple application-level workaround for it.
- http://bugs.impara.de/view.php?id=4882 (VM lockup)
John has replied to that one as well (and not being a Unix guy I have nothing to add).
Regards, - Andreas
On Mon, Sep 25, 2006 at 09:33:08PM +0200, Adrian Lienhard wrote:
On Sep 25, 2006, at 21:11 , Brad Fuller wrote:
Brad Fuller wrote:
tim Rowledge wrote:
Wouldn't the VM Crash, that I and others reported, be a reason not to release until fixed? Mantis issue# 0005056
brad
No comment on my question?
I think, the current VM issues would be a good reason to pospone the release.
Unless there is some reason to believe that this issue is related to the image, it should have no bearing on the question of whether the Squeak 3.9 image should or should not be released. The fact that someone happened to have been running a 3.9 image when they observed the problem is probably irrelevant (but it would be helpful if someone who is experiencing the problem could confirm or deny this by testing for the bug on a 3.8 image).
Unfortunately, as it seems to me, the VM is quite poorly maintained. Probably the main reason being that the maintainers don't have enough time (or, in other words, because they are not paid to fix the problems). Another difficulty is that there are only few people that actually work on the VM (why?).
Actually, it's kind of fun, and anybody with an interest in the topic can do it. As for myself, none of the computers I have access to exhibit the problem you are discussing, so it's not very far up the list of itches I want to scratch. But if your system is crashing, you are in an ideal position to have a look at it.
It's certainly possible that a bit of funding might lubricate the maintenance process, but in the mean time there is nothing stopping you or me or anybody else from working on any of these issues. If you wait for "somebody else" to work on it, you may be waiting a long time.
Folks, this is open source. Including the VM.
Dave
Sure but if we do not say that it is final then not enough people look at it. So at some points we should stop.
A possibility is to declare this version final and release 3.9.1 in a month. Or we can wait a week and declare it final.
On 22-Sep-06, at 6:02 AM, stephane ducasse wrote:
includes cs fix and required traits fixes
is out and I would consider it as final.
Sounds promising. Might I suggest allowing a week for possible problems before blessing it? There are few thigs quite as embarrassing as declaring a final version and finding out you forgot something crucial. DAMHIKT, as they say in the woodworking world.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- PORTE-KOCHERE - Sacramental wine
stephane ducasse writes:
Sure but if we do not say that it is final then not enough people look at it. So at some points we should stop.
A possibility is to declare this version final and release 3.9.1 in a month. Or we can wait a week and declare it final.
I'd argue for waiting a week then declaring it final.
You've got a release candidate (or gamma). Release unless there's a critical bug. So no more fixes unless someone finds a bug that's worth waiting a few more weeks.
i.e. relax, and ask people to test.
Bryce
On 23-Sep-06, at 9:37 AM, Bryce Kampjes wrote:
stephane ducasse writes:
Sure but if we do not say that it is final then not enough people look at it. So at some points we should stop.
A possibility is to declare this version final and release 3.9.1 in a month. Or we can wait a week and declare it final.
I'd argue for waiting a week then declaring it final.
You've got a release candidate (or gamma). Release unless there's a critical bug. So no more fixes unless someone finds a bug that's worth waiting a few more weeks.
i.e. relax, and ask people to test.
Exactly; think of this as RC1, watch the reports and if all seems reasonable after a week, relabel it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Resistance is useless! (If << 1 ohm)
Thanks for the great work, Stéphane, Markus and all the others !
I think now we have to setup a "3.9 release team" in order to take care of the stable 3.9 branch (3.9.1, 3.9.2, ...). Maybe the same team could make the job. Only bug fixing, documentation, and maybe tests should be added in the stable branch, no more new features. The new features should be only in the new 3.10 branch.
-- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO http://purl.org/net/SergeStinckwich oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##
3.9 is looking great!
I was wondering though about the default colours of the SqueakMap browser.
Does anyone get the same effect as me? I don't think the transparency is working properly and the scroll bar arrows don't display. When I go to adjust the transparency it repairs itself but at 100% opaqueness.
Any thoughts? It might be an idea to repair the colour in the image if everyone gets this.
Cheers,
Mike
yeap this is a problem but not a show stopper for me. :)
So if someone fix it we may include in RC2.
Stef
On 24 sept. 06, at 20:00, Michael Roberts wrote:
3.9 is looking great!
I was wondering though about the default colours of the SqueakMap browser.
<squeak-map1.png>
Does anyone get the same effect as me? I don't think the transparency is working properly and the scroll bar arrows don't display. When I go to adjust the transparency it repairs itself but at 100% opaqueness.
Any thoughts? It might be an idea to repair the colour in the image if everyone gets this.
Cheers,
Mike
I thought that the 3.8 image had a great look and feel. I am curious as to why it was determined that it needed a look enhancement. I think somebody's grandfather had once said, "If it aint' broken don't fix it" :)
-bakki
PS: In addition to the issue Michael mentions some of the other behavioural problems are: 1. Windows can only be resized by dragging corners. It is very convenient to be able to do it also by dragging the borders. 2. Resizing Monticello browser stretches the buttons at top to ugly proportions. (layout problem)
On 9/24/06, stephane ducasse stephane.ducasse@gmail.com wrote:
yeap this is a problem but not a show stopper for me. :)
So if someone fix it we may include in RC2.
Stef
I thought that the 3.8 image had a great look and feel. I am curious as to why it was determined that it needed a look enhancement. I think somebody's grandfather had once said, "If it aint' broken don't fix it" :)
-bakki
It was broke, it was ugly as hell and looked like a toy (be design, being for kids). It needed a more professional look, to be used by more professionals. The latest look enhancements also added a nicety of double clicking the title bar to minimize and maximize, like other windowing systems.
Ramon Leon http://onsmalltalk.com
"But Squeak is only a toy." - "Yes, thanks to God!" - anonymous vs. squeakerI m very happy coz i m still a kid.
It wasn't broken technically anyway.
On 9/25/06, Ramon Leon ramonleon@cox.net wrote:
I thought that the 3.8 image had a great look and feel. I am curious as to why it was determined that it needed a look enhancement. I think somebody's grandfather had once said, "If it aint' broken don't fix it" :)
-bakki
It was broke, it was ugly as hell and looked like a toy (be design, being for kids). It needed a more professional look, to be used by more professionals. The latest look enhancements also added a nicety of double clicking the title bar to minimize and maximize, like other windowing systems.
Ramon Leon http://onsmalltalk.com
So Squeak is not meant to build commercial products (Impara, Smallthought, ... )?
To be honest I have a hard time renumbering the last time SqueakMap worked and did not throw an obscure error at me.
That's why I prefer to have all my packages in Monticello, just hit load and it works.
Philippe
2006/9/25, Hiren Thacker hithacker@gmail.com:
"But Squeak is only a toy." - "Yes, thanks to God!" - anonymous vs. squeakerI m very happy coz i m still a kid.
It wasn't broken technically anyway.
On 9/25/06, Ramon Leon < ramonleon@cox.net> wrote:
I thought that the 3.8 image had a great look and feel. I am curious as to why it was determined that it needed a look enhancement. I think somebody's grandfather had once said, "If it aint' broken don't fix it" :)
-bakki
It was broke, it was ugly as hell and looked like a toy (be design, being for kids). It needed a more professional look, to be used by more professionals. The latest look enhancements also added a nicety of double clicking the title bar to minimize and maximize, like other windowing systems.
Ramon Leon http://onsmalltalk.com
-- Hiren J.Thacker
So Squeak is not meant to build commercial products (Impara, Smallthought, ... )?
To be honest I have a hard time renumbering the last time SqueakMap worked and did not throw an obscure error at me.
That's why I prefer to have all my packages in Monticello, just hit load and it works.
Philippe
Seaside is changing that, Squeak is perfect for writing commercial web applications.
Ramon Leon http://onsmalltalk.com
2006/9/25, Ramon Leon ramon.leon@allresnet.com:
So Squeak is not meant to build commercial products (Impara, Smallthought, ... )?
To be honest I have a hard time renumbering the last time SqueakMap worked and did not throw an obscure error at me.
That's why I prefer to have all my packages in Monticello, just hit load and it works.
Philippe
Seaside is changing that, Squeak is perfect for writing commercial web applications.
Not perfect. Not even close. Just look at the hacks introduced in Seaside2.7a1-avi.10 because blocks in Squeak suck.
Do you know how many times I got bitten (doing commercial web applications) because I forgot to add a #fixTemps? It can tell you one thing, if Java 1.7 will get closures, it will not require #fixTemps.
Then there are all these VM horror stories. And don't get me started on persistence, or XML, or SOAP, or concurrency, or ... or IO in general, urls, ... or browsers
Philippe
Seaside is changing that, Squeak is perfect for writing
commercial web
applications.
Not perfect. Not even close. Just look at the hacks introduced in Seaside2.7a1-avi.10 because blocks in Squeak suck.
Yea, I know, I guess perfect was an overstatement.
Do you know how many times I got bitten (doing commercial web applications) because I forgot to add a #fixTemps? It can tell you one thing, if Java 1.7 will get closures, it will not require #fixTemps.
Nor does Squeak, if you use the new closure compiler, however, Seaside attempts to do all the #fixTemps for you, you shouldn't have to think about. I do lot's of seaside code and never have to call #fixTemps myself.
Then there are all these VM horror stories. And don't get me started on persistence, or XML, or SOAP, or concurrency, or ... or IO in general, urls, ... or browsers
Philippe
Xml's a bit odd, I admit, SOAP though, works great. I use SOAP between Squeak and .Net daily, it's rock solid so far. I had to beg the author of SoapCore to add .Net support initially, since .Net's a bit odd, but since then it's been great. Squeak isn't perfect, but it's better than anything else I've seen.
Ramón León http://onsmalltalk.com
Do you know how many times I got bitten (doing commercial web applications) because I forgot to add a #fixTemps? It can tell you one thing, if Java 1.7 will get closures, it will not require #fixTemps.
Nor does Squeak, if you use the new closure compiler, however, Seaside attempts to do all the #fixTemps for you, you shouldn't have to think about. I do lot's of seaside code and never have to call #fixTemps myself.
Closure compiler makes all blocks slower (not what you want for Seaside) and doesn't work with exceptions.
Then there are all these VM horror stories. And don't get me started on persistence, or XML, or SOAP, or concurrency, or ... or IO in general, urls, ... or browsers
Philippe
Xml's a bit odd, I admit, SOAP though, works great. I use SOAP between Squeak and .Net daily, it's rock solid so far. I had to beg the author of SoapCore to add .Net support initially, since .Net's a bit odd, but since then it's been great. Squeak isn't perfect, but it's better than anything else I've seen.
So the security hole that allowed arbitrary code execution is fixed? How do you use SSL together with SOAP?
Philippe
Closure compiler makes all blocks slower (not what you want for Seaside) and doesn't work with exceptions.
Ok, true.
So the security hole that allowed arbitrary code execution is fixed?
Didn't know about that, got a link to more info?
How do you use SSL together with SOAP?
Philippe
I'd use stunnel, since squeak doesn't do SSL, and stunnel works quite well.
Philippe,
I think that you work too much with marcus :) Been right does not mean to be bitter or negativist :) We can change that. Step by step. We did a lot in 3.9 and if people help/want we can do a lot in 3.10 too.
send fixes and we will consider them
Stef
So Squeak is not meant to build commercial products (Impara, Smallthought, ... )?
To be honest I have a hard time renumbering the last time SqueakMap worked and did not throw an obscure error at me.
That's why I prefer to have all my packages in Monticello, just hit load and it works.
Philippe
Seaside is changing that, Squeak is perfect for writing commercial web applications.
Not perfect. Not even close. Just look at the hacks introduced in Seaside2.7a1-avi.10 because blocks in Squeak suck.
Do you know how many times I got bitten (doing commercial web applications) because I forgot to add a #fixTemps? It can tell you one thing, if Java 1.7 will get closures, it will not require #fixTemps.
Then there are all these VM horror stories. And don't get me started on persistence, or XML, or SOAP, or concurrency, or ... or IO in general, urls, ... or browsers
Philippe
Hi!
"Philippe Marschall" philippe.marschall@gmail.com wrote:
So Squeak is not meant to build commercial products (Impara, Smallthought, ... )?
To be honest I have a hard time renumbering the last time SqueakMap worked and did not throw an obscure error at me.
Eh, I am not sure how SqueakMap came into this thread but anyway:
What error do you get? Doesn't it work for you now?
I am aware of a few current bugs or "inconveniences" but generally I think SM works ok in 3.8+.
regards, Göran
2006/9/25, goran@krampe.se goran@krampe.se:
Hi!
"Philippe Marschall" philippe.marschall@gmail.com wrote:
So Squeak is not meant to build commercial products (Impara, Smallthought, ... )?
To be honest I have a hard time renumbering the last time SqueakMap worked and did not throw an obscure error at me.
Eh, I am not sure how SqueakMap came into this thread but anyway:
What error do you get? Doesn't it work for you now?
Pick one. If none of the other shows up, you can be sure an EOCD error pops up. Then I usally download and install the file manually. I don't know why SqueakMap can't do that for me.
Philippe
I am aware of a few current bugs or "inconveniences" but generally I think SM works ok in 3.8+.
regards, Göran
Hi!
"Philippe Marschall" philippe.marschall@gmail.com wrote:
2006/9/25, goran@krampe.se goran@krampe.se:
Hi!
"Philippe Marschall" philippe.marschall@gmail.com wrote:
So Squeak is not meant to build commercial products (Impara, Smallthought, ... )?
To be honest I have a hard time renumbering the last time SqueakMap worked and did not throw an obscure error at me.
Eh, I am not sure how SqueakMap came into this thread but anyway:
What error do you get? Doesn't it work for you now?
Pick one.
Pick one? What do you mean?
If none of the other shows up, you can be sure an EOCD error pops up.
Yes, this is an unfortunate situation that I need to go through. The problem is that after I introduced the server side cache and SHA checksumming apparently lots of releases either were non-available at the time I initially populated the cache (which lead to crap files in the server cache, and to make things worse - crappy checksums!) OR have been unavailable when releases have been registered. I think.
At least that is the current state. If you open a transcript when trying to install/download something and it complains about the checksum and "trying server cache" then there may very well be a problem. It compared the faulty checksum with the correct (presumably) data from the original URL and then decides to use the server side cache instead which contains faulty data. Not very helpful ;).
Then I usally download and install the file manually. I don't know why SqueakMap can't do that for me.
Because there is no such menu choice today (one that ignores the SHA checksum and just downloads anyway). I can add one though.
The real medicine is probably to clean the server side cache and/or figure out why it got filled with bad data in the first place.
And we could also thirdly add a button somewhere in the map web UI to "repopulate server cache and recalculcate SHA checksum". That is done automatically whenever you modify the URL of a release today - but it could be helpful to have such a button to "repair" entries.
Philippe
regards, Göran
Hi goran
I know that this is a responsibility to be the father of a success. ;) But indeed this would be good if we could get SM working full speed. So if you could allocate some time on that this would be great.
Stef
goran@krampe.se writes:
Yes, this is an unfortunate situation that I need to go through. The problem is that after I introduced the server side cache and SHA checksumming apparently lots of releases either were non-available at the time I initially populated the cache (which lead to crap files in the server cache, and to make things worse - crappy checksums!) OR have been unavailable when releases have been registered. I think.
I run into this as well if SqueakMap downloads while the network is unavailable. It saves to the file an error message, and so of course its checksum is wrong. So, the tool could be more careful about checking that the HTTP request worked, before saving the file.
Recursive delete on the SqueakMap directories works fine in this case. You can then restart SqueakMap and it will repopulate its directories from the network.
I also ran into this when I tried to update the URL of a released SqueakMap version. Maybe this is more in the line of what you discuss with bad cached information on the server. I ended up bumping the version number even though the actual file content had not changed.
-Lex
Hi Lex!
Lex Spoon lex@cc.gatech.edu wrote:
goran@krampe.se writes:
Yes, this is an unfortunate situation that I need to go through. The problem is that after I introduced the server side cache and SHA checksumming apparently lots of releases either were non-available at the time I initially populated the cache (which lead to crap files in the server cache, and to make things worse - crappy checksums!) OR have been unavailable when releases have been registered. I think.
I run into this as well if SqueakMap downloads while the network is unavailable. It saves to the file an error message, and so of course its checksum is wrong. So, the tool could be more careful about checking that the HTTP request worked, before saving the file.
Ah. Yes... I will take a look (if I remember :)).
Recursive delete on the SqueakMap directories works fine in this case. You can then restart SqueakMap and it will repopulate its directories from the network.
Right, but this is the client side cache you are talking about (just so other non familiar readers follow).
I also ran into this when I tried to update the URL of a released SqueakMap version. Maybe this is more in the line of what you discuss with bad cached information on the server. I ended up bumping the version number even though the actual file content had not changed.
IIRC the current logic is that when the URL of a release is modified - it will repopulate the server side cache and update the checksum, Was that what you tried to do? Because I thought that worked.
But just so that any confused reader understand - if the SM server at that time downloads a "faulty" file - like say an HTTP error message instead of a sar-file - then from that moment it will end up being very inhelpful thinking that any subsequent correct download is in fact bad (checksum fails) and it will fall back on downloading the faulty file from the server side cache.
I can't come up with an easy way to sweep and fix this. Any bright ideas? Except for adding tons of sanity checks on received data - which on the other hand might not be that hard - recognizing our most popular formats might be enough.
regards. Göran
lex@lexspoon.org writes:
I also ran into this when I tried to update the URL of a released SqueakMap version. Maybe this is more in the line of what you discuss with bad cached information on the server. I ended up bumping the version number even though the actual file content had not changed.
goran@krampe.se writes:
IIRC the current logic is that when the URL of a release is modified - it will repopulate the server side cache and update the checksum, Was that what you tried to do? Because I thought that worked.
Before reading this thread, I did not know there was a server-side cache at all!
Anyway, yes, I tried to update the card for Universes version 9 to point to SqueakSource's new host name (i.e., swapping the unibe.ch name for squeaksource.com). For whatever reason, I could not get it to work, so I instead posted a version 9b.
I am not sure a separate 9b card is a bad idea, anyway. The version 9 card is already published, and, philosophically, mutating a published card seems a little weird.
-Lex
Lex Spoon lex@cc.gatech.edu wrote:
lex@lexspoon.org writes:
I also ran into this when I tried to update the URL of a released SqueakMap version. Maybe this is more in the line of what you discuss with bad cached information on the server. I ended up bumping the version number even though the actual file content had not changed.
goran@krampe.se writes:
IIRC the current logic is that when the URL of a release is modified - it will repopulate the server side cache and update the checksum, Was that what you tried to do? Because I thought that worked.
Before reading this thread, I did not know there was a server-side cache at all!
Anyway, yes, I tried to update the card for Universes version 9 to point to SqueakSource's new host name (i.e., swapping the unibe.ch name for squeaksource.com). For whatever reason, I could not get it to work, so I instead posted a version 9b.
I am not sure a separate 9b card is a bad idea, anyway. The version 9 card is already published, and, philosophically, mutating a published card seems a little weird.
Exactly.
Well, I will just have to test it myself again. I can't say why it didn't work for you.
regards, Göran
"But Squeak is only a toy." - "Yes, thanks to God!" - anonymous vs. squeaker
I m very happy coz i m still a kid.
Still I hope that the work of henrik rescued by Andy will help us improving the overall look of Squeak (een the feel could be better). Let us adpot a little step at a time and make sure that we do a lot of them. So sophie enhancements are important
Stef
Still I hope that the work of henrik rescued by Andy will help us improving the overall look of Squeak
This is really over over over my head ;-)
But it is very interesting to know that the overall look of Squeak can be improved with modularization. ;-)
Cheers,
SmallSqueak
----- Original Message ----- From: "stephane ducasse" stephane.ducasse@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, September 25, 2006 2:41 PM Subject: Re: Squeak map colours
"But Squeak is only a toy." - "Yes, thanks to God!" - anonymous vs. squeaker
I m very happy coz i m still a kid.
Still I hope that the work of henrik rescued by Andy will help us improving the overall look of Squeak (een the feel could be better). Let us adpot a little step at a time and make sure that we do a lot of them. So sophie enhancements are important
Stef
"SmallSqueak" smallsqueak@rogers.com wrote:
Still I hope that the work of henrik rescued by Andy will help us improving the overall look of Squeak
This is really over over over my head ;-) But it is very interesting to know that the overall look of Squeak can be improved with modularization. ;-)
He did not refer to the modules work by Henrik - he referred to the look enhancements and primarily I guess the sub pixel font rendering etc.
regards, Göran
I thought that the 3.8 image had a great look and feel.
IMO, 3.9 looks not better than 3.8. I liked "Out of the box" and "Bright squeak" in 3.6 . They looked more consistent for me. Perhaps aesthetics is subjective thing. But squeak 3.9 can not change themes ( http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-February/100944....).
Marcus noted about reasons for that: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-February/100953....
Vaidotas Didžbalis,
squeak-dev@lists.squeakfoundation.org
-
Adrian Lienhard -
Alan Grimes -
Andreas Raab -
Andrew Tween -
Bakki Kudva -
Bert Freudenberg -
Brad Fuller -
Bryce Kampjes -
David T. Lewis -
Diego Gomez Deck -
Giovanni Corriga -
goran＠krampe.se -
Hiren Thacker -
John M McIntosh -
Lex Spoon -
Lukas Renggli -
Marcus Denker -
Michael Roberts -
Milan Zimmermann -
Pavel Krivanek -
Philippe Marschall -
Ramon Leon -
Ramon Leon -
Serge Stinckwich -
SmallSqueak -
stephane ducasse -
tim Rowledge -
Vaidotas Didžbalis