headers
Charles A. Monteiro | 1 Mar 2006 06:02

Re: stdout n Windows

why? Also, the ImageConfigurationSubystem does close it although it is  
done apparently right before the image shutdowns, see code attached below.  
I would think that the sheer fact that the image shutdowns releases the  
stream. Here is another question. let's say that VW opens a bunch of  
external streams but does not close them, if then VW shuts done is part of  
shutting down the closing of said streams i.e those found in "OpenStreams"  
or is it that Windows closes them once it sees the process for VW go away  
or are those streams just left open?

ImageConfigurationSubsystem>>
runCodeAndThenQuit: argumentStream
	"This allows you to run arbitrary code from the command line, specified a  
Smalltalk string to be evaluated. After evaluation, the string will be  
printed to standard out and the image will quit. Make very sure that we  
always quit, even if closing the stream doesn't work."

	<option: '-evaluate'>

	| expressions result |
	[
	self class allowExpressions ifFalse: [^self].
	[expressions := CommandLineInterest argumentsFrom: argumentStream.
	expressions
		do:
			[:each |
			result := Compiler evaluate: each.
			self stdout nextPutAll: result displayString]] ensure: [self stdout  
close]] ensure: [ObjectMemory quit].

On Tue, 28 Feb 2006 12:55:50 -0500, Alan Knight <knight <at> acm.org> wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles A. Monteiro | 1 Mar 2006 06:34

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

yes, it depends on what he is doing. If creating classes and methods at  
runtime one may not care. However, if you want to co-exist with the VW IDE  
i.e. in dev mode you will certainly care. The following are the dependents  
of ChangeSet in my image, note that because the printStrings for some of  
these are quite involved I simplified by just collecting the associated  
"instanceBehavior(s)"

#(Parcel Override Refactory.Browser.RefactoryChangeManager ChangeHistorian  
NamespaceChangeListener Store.XMainChangeSet MiniChangeSetManager  
Refactory.Browser.PundleNavigatorPart Refactory.Browser.ClassNavigatorPart  
Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool  
Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool  
Refactory.Browser.SharedVariableProtocolNavigatorPart  
Refactory.Browser.SharedVariableNavigatorPart  
Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool)

these all seem to be very much about the IDE. Having said that I think I  
will check out what the NamespaceChangeListener does.

-Charles
On Tue, 28 Feb 2006 13:07:13 -0500, Alan Knight <knight <at> acm.org> wrote:

> I wouldn't turn off notification, you're likely to confuse a bunch of  
> other structures. Besides, it's relatively easy to compile without  
> logging. For example, with Store loaded, see  
> ClassDescription>>compileWithoutStoringSource:classified:. That's a  
> shortcut used to improve Store source load times by compiling  
> everything, then doing all of the logging at once. But in general, the  
> part that compiles is separate from the part that logs. For another  
> example, see
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ladislav Lenart | 1 Mar 2006 10:04
Picon

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Charles A. Monteiro wrote:

> yes, it depends on what he is doing. If creating classes and methods 
> at  runtime one may not care. However, if you want to co-exist with 
> the VW IDE  i.e. in dev mode you will certainly care. The following 
> are the dependents  of ChangeSet in my image, note that because the 
> printStrings for some of  these are quite involved I simplified by 
> just collecting the associated  "instanceBehavior(s)"

Well, I am doing all this in development image in unit tests, so I would 
like to coexist with browsers but in the same time I don't want these 
changes made in tests written to the ChangeSet...

And what about my other question, there is really no one out there who 
can explain that to me? :-)

Ladislav Lenart

>
> #(Parcel Override Refactory.Browser.RefactoryChangeManager 
> ChangeHistorian  NamespaceChangeListener Store.XMainChangeSet 
> MiniChangeSetManager  Refactory.Browser.PundleNavigatorPart 
> Refactory.Browser.ClassNavigatorPart  
> Refactory.Browser.MethodNavigatorPart 
> Refactory.Browser.BrowserCodeTool  
> Refactory.Browser.MethodNavigatorPart 
> Refactory.Browser.BrowserCodeTool  
> Refactory.Browser.SharedVariableProtocolNavigatorPart  
> Refactory.Browser.SharedVariableNavigatorPart  
> Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Steven Kelly | 1 Mar 2006 10:35
Favicon

RE: Question about Behavior>>flushVMmethodCacheEntriesFor:

> And what about my other question, there is really no one 
> out there who can explain that to me? :-)

I think it would be safe to assume that the percentage of the world's
population who can _explain_ that is around 0.000000015%. We've enjoyed
the intricacies of flushVMmethodCache* for around 13 years, and I can't
claim to fully understand it. The only way to do that is read the VM
source code (oh, and get a PhD or greater experience in VMs, PICs etc.).
In an attempt to keep what's left of my sanity and productivity, I've
tried to avoid doing either.

I would suspect the cause is a bug, most probably introduced with all
the wonderful VM speed optimizations we've been enjoying. A simplistic
VM would probably behave like you imagined, and simply run the old
version; VW's VM is one of the most powerful out there, and far from
simplistic. "Normal" use of VW won't hit the problem, because both image
and VM are pretty aggressive about throwing away the whole VMmethodCache
on the slightest change. 

Given what happens when you leave old stuff in the cache - as you have
seen - that's perhaps understandable. flushVMmethodCache tends to be
pretty expensive, though, so if you have an application that invokes
code that invokes the flush (e.g. recompiling a class), it can mount up.
Our database app was doing that several hundred times on each commit,
which became the major factor. We tried to set things up so it was
called only once at the end (we knew no methods from the classes in
question would be called in the interim). Oddly, this didn't work: the
image did the calls, but the cache for the classes in question was not
flushed. Eliot tried to explain this, but I think we didn't fully
understand each other - although I certainly learned a lot. In the end,
(Continue reading)

Permalink | Reply | 10 comments |
headers
Reinout Heeck | 1 Mar 2006 10:37
Favicon

Re: Two store questions

Alan Knight wrote:
> A relatively simple workaround would be to save the primary key of the
> packages you plan to load, either instead of or as well as the version
> number. Or, when it goes to load, checking that the version number is in
> fact unique, and you don't get two or more packages back from that query,
> and crashing quickly if there are. Or you could build the list and then do
> the load all within a transaction.

Weighing effort versus effect I guess simply adding the DB constraint will be 
my first act, it avoids the entire problem albeit at the cost of confusing 
error reporting. Using a transaction sounds like a good idea ot follow up on.

> A newest with blessing level above X approach also seems susceptible to
> corruption when the blessing level changes.

Correct, hence we use Lineups in other stages of our process. (A Lineup 
effectively publishes the aforementioned list of versioned prereqs). 

R
-
Permalink | Reply | 0 comments |
headers
Mülheims, Klaus | 1 Mar 2006 10:39
Picon

AW: [7.4] Lens broken

Hi Alan,
 
thanks for creating AR. I will build a test-image for pre-production tests to proof, if there are any
problems with my workaround.
 
Greetings
 
Klaus
 
Collogia AG
Ubierring 11
 
50678 Köln
Germany
+49 221 336080
http://www.collogia.de

 

________________________________

Von: Alan Knight [mailto:knight <at> acm.org] 
Gesendet: Dienstag, 28. Februar 2006 18:45
An: =?iso-8859-1?Q?M=C3=BClheims?= <at> mailrelay.netcologne.de; Mülheims, Klaus; vwnc <at> cs.uiuc.edu
Betreff: Re: [7.4] Lens broken


Thanks. I've created AR 50418 for this. On a guess, these methods were removed because of changes to
bytecodes in 7.4, for example, to remove limits on jump distances, and the methods were not kept up to date
on those changes. As such, I'm not sure if the old versions will actually work or not, but if they're broken
it's possible they'd only be broken for e.g. very long methods. If they seem to work for your cases, then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reinout Heeck | 1 Mar 2006 11:19
Favicon

Re: Two store questions

Steven Kelly wrote:
>
> If Reinout would really still hit this problem often with only 4-6
> pairs,

I don't know how often this occurs. Personally I've seen this problem once, I 
don't know how often it happens under the radar.

> I think he could be encouraged to look at whether his work 
> process is a contributory factor, not just Store. If every pair is 
> encouraged to edit the same pundle often - to exaggerate, say an
> "AllSoopsStuff" bundle, which everybody is asked to update and publish
> whenever they publish a package - then that bundle will of course be a
> hotspot for locking conflicts. That's bad, even if Store would recognise
> the conflicts.

See 
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3265388740
for some of my views on bundles and our process.

> Version control systems that allow forks are simply not 
> built to implement a single version path, where everyone is constantly
> adding a new version.

We are not simply adding, we rely on the publish dialog to tell us whether a 
merge is necessary: if dotted versions appear I have to merge after the 
publishing to bring my changes into the head version. The bug under 
discussion endangers this process.

> Would the above suggestion help, Reinout? What if we extended it so at
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reinout Heeck | 1 Mar 2006 11:29
Favicon

Re: schizo-socket

Bruce Badger wrote:
>
> But really all I'm suggesting is that a VW programmer experiences some
> sanity.  Having a socket first say there *is* some data and then when
> asked for it denying that there is any is not sane at all.

It is not saying there is data: it quite literally says that it is done 
waiting.

It is more like #atEnd, which will return if data is available or the stream 
is closed, but will block otherwise.

HTH,

Reinout
-------
Permalink | Reply | 7 comments |
headers
Reinout Heeck | 1 Mar 2006 11:49
Favicon

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Steven Kelly wrote:
>
> 1) create a minimal test case that exhibits the crash, and send it to
> Cincom support

Pretty please.
This probably involves quite a bit of effort from your side but in the past we 
have enabled Eliot to flush out GC bugs that confounded him. A repeatable 
case provides the leverage to get it fixed.

'Pretty please' because we are currently suffering VM crashes in mmScavenge in 
one of our projects, the more datapoints others can offer us the more we are 
helped :-)

R
-
Permalink | Reply | 1 comment |
headers
Holger Kleinsorgen | 1 Mar 2006 12:03
Picon
Favicon

Dialog requestFileName

Hi,

7.4 still has the habit of ignoring the given message when requesting a 
filename. Instead, there is some *cough* interesting sniffing code:

looksLikeSaveFileMessage: aString
    | noCaseMessage messages |
    noCaseMessage := aString asLowercase.
    messages := (#saveKeywords << #labels >> 'save\out\write') asString.
    messages := messages tokensBasedOn: $\.
    ^messages contains:
       [:clue |
       (noCaseMessage findString: clue startingAt: 1) ~= 0]

This leads to some odd results:

On a win32 machine (German language)
"Dialog requestFileName: 'Choose heavenly file'"
will open a file dialog with the window title
"Öffnen"

Linux (German)
"Dialog requestFileName: 'Choose heavenly file'"
==> "Open File"

Win32 (German)
"Dialog requestFileName: 'Choose file out of hell'"
==> "Datei speichern unter"

Linux (German)
(Continue reading)

Permalink | Reply | 17 comments |

Gmane