ExternalDictionary corrupted in Store?
Locked
ExternalDictionary corrupted in Store?
 
|
When I load WinService versions 1.0.9 or earlier from the public Store
into VW 7.4.1, its DLLCC code looks right but most of the procedures fail. E.g. try running the following line, which should do nothing (unless you have a Windows service called foobar!): WinServiceInterface new deregisterService: 'foobar' It gives an "Invalid procedure argument" error, because the function, defined as void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) is in the ExternalDictionary as: void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, LPCSTR DWORD) i.e. the last parameter has kept the LPCSTR type of the previous argument, and changed DWORD from being the type into being the parameter name. Recompiling the class (e.g. by switching to #debug then back to #full) gets rid of the problem. But how can I get that change into Store? And how did it get there in the first place? The problem is in all versions of WinService before today, dating back to 2004. It looks like the variables listed as undeclared in the Transcript when loading are the problems (log below). As a workaround, 1.0.10 adds a postLoadBlock to recompileMethods. Any clues as to how this should be solved properly? Cheers, Steve Loading WinService . . . (WinServiceInterface #StartService:with:with: - _arg1 is undeclared) (WinServiceInterface #StartService:with:with: - DWORD is undeclared) (WinServiceInterface #StartService:with:with: - _arg2 is undeclared) (WinServiceInterface #QueryServiceConfig:with:with:with: - LPQUERY_SERVICE_CONFIG is undeclared) (WinServiceInterface #QueryServiceConfig:with:with:with: - PDWORD is undeclared) (WinServiceInterface #EnumServicesStatus:with:with:with:with:with:with:with: - LPENUM_SERVICE_STATUS is undeclared) (WinServiceInterface #SetServiceStatus:with: - LPSERVICE_STATUS is undeclared) (WinServiceInterface #GetServiceDisplayName:with:with:with: - _arg3 is undeclared) (WinServiceInterface #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi th: - _arg4 is undeclared) (WinServiceInterface #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi th: - _arg5 is undeclared) (WinServiceInterface #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi th: - _arg6 is undeclared) (WinServiceInterface #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi th: - _arg7 is undeclared) (WinServiceInterface #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi th: - _arg8 is undeclared) (WinServiceInterface #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi th: - _arg9 is undeclared) (WinServiceInterface #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi th: - _arg10 is undeclared) (WinServiceInterface #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi th: - _arg11 is undeclared) (WinServiceInterface #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi th: - _arg12 is undeclared) (WinServiceInterface #SetServiceObjectSecurity:with:with: - PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface #QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is undeclared) Done |
Re: ExternalDictionary corrupted in Store?
|
|
Steven,
This issue has been recently rectified in VW. It has to do with the fact that, upon loading, the order in which type definitions are compiled has an influence in their final meaning. Thanks, Andres. Steven Kelly wrote: > When I load WinService versions 1.0.9 or earlier from the public Store > into VW 7.4.1, its DLLCC code looks right but most of the procedures > fail. E.g. try running the following line, which should do nothing > (unless you have a Windows service called foobar!): > > WinServiceInterface new deregisterService: 'foobar' > > It gives an "Invalid procedure argument" error, because the function, > defined as > > void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) > > is in the ExternalDictionary as: > > void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, LPCSTR DWORD) > > i.e. the last parameter has kept the LPCSTR type of the previous > argument, and changed DWORD from being the type into being the parameter > name. > > Recompiling the class (e.g. by switching to #debug then back to #full) > gets rid of the problem. But how can I get that change into Store? And > how did it get there in the first place? > > The problem is in all versions of WinService before today, dating back > to 2004. It looks like the variables listed as undeclared in the > Transcript when loading are the problems (log below). As a workaround, > 1.0.10 adds a postLoadBlock to recompileMethods. Any clues as to how > this should be solved properly? > > Cheers, > Steve > > Loading WinService . . . > (WinServiceInterface #StartService:with:with: - _arg1 is undeclared) > (WinServiceInterface #StartService:with:with: - DWORD is undeclared) > (WinServiceInterface #StartService:with:with: - _arg2 is undeclared) > (WinServiceInterface #QueryServiceConfig:with:with:with: - > LPQUERY_SERVICE_CONFIG is undeclared) > (WinServiceInterface #QueryServiceConfig:with:with:with: - PDWORD is > undeclared) > (WinServiceInterface > #EnumServicesStatus:with:with:with:with:with:with:with: - > LPENUM_SERVICE_STATUS is undeclared) > (WinServiceInterface #SetServiceStatus:with: - LPSERVICE_STATUS is > undeclared) > (WinServiceInterface #GetServiceDisplayName:with:with:with: - _arg3 is > undeclared) (WinServiceInterface > #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi > th: - _arg4 is undeclared) > (WinServiceInterface > #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi > th: - _arg5 is undeclared) > (WinServiceInterface > #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi > th: - _arg6 is undeclared) > (WinServiceInterface > #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi > th: - _arg7 is undeclared) > (WinServiceInterface > #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi > th: - _arg8 is undeclared) > (WinServiceInterface > #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi > th: - _arg9 is undeclared) > (WinServiceInterface > #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi > th: - _arg10 is undeclared) > (WinServiceInterface > #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi > th: - _arg11 is undeclared) > (WinServiceInterface > #CreateService:with:with:with:with:with:with:with:with:with:with:with:wi > th: - _arg12 is undeclared) > (WinServiceInterface #SetServiceObjectSecurity:with:with: - > PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface > #QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is > undeclared) > Done > > > |
RE: ExternalDictionary corrupted in Store?
|
|
In reply to this post by Steven Kelly
Yes, that makes sense: the procedures are being compiled before the
types, so DWORD etc. aren't available. Presumably the solution is twofold: 1) correct the order on load, and 2) also publish in the right order (for older VWs to be able to load correctly). Is 2) implemented in the latest VW dev version? BTW, why aren't we seeing this more? The order in Store appears random, so I'd imagine most ExternalInterface packages would have this problem in at least some procedures. Thanks, Steve > -----Original Message----- > From: Andres Valloud [mailto:[hidden email]] > Sent: 1. marraskuuta 2007 19:53 > To: [hidden email] > Subject: Re: ExternalDictionary corrupted in Store? > > > Steven, > > This issue has been recently rectified in VW. It has to do with the > fact that, upon loading, the order in which type definitions are > compiled has an influence in their final meaning. > > Thanks, > Andres. > > Steven Kelly wrote: > > When I load WinService versions 1.0.9 or earlier from the > public Store > > into VW 7.4.1, its DLLCC code looks right but most of the > procedures > > fail. E.g. try running the following line, which should do nothing > > (unless you have a Windows service called foobar!): > > > > WinServiceInterface new deregisterService: 'foobar' > > > > It gives an "Invalid procedure argument" error, because the > function, > > defined as > > > > void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) > > > > is in the ExternalDictionary as: > > > > void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, LPCSTR DWORD) > > > > i.e. the last parameter has kept the LPCSTR type of the previous > > argument, and changed DWORD from being the type into being the > > parameter name. > > > > Recompiling the class (e.g. by switching to #debug then > back to #full) > > gets rid of the problem. But how can I get that change into > Store? And > > how did it get there in the first place? > > > > The problem is in all versions of WinService before today, > dating back > > to 2004. It looks like the variables listed as undeclared in the > > Transcript when loading are the problems (log below). As a > workaround, > > 1.0.10 adds a postLoadBlock to recompileMethods. Any clues > as to how > > this should be solved properly? > > > > Cheers, > > Steve > > > > Loading WinService . . . > > (WinServiceInterface #StartService:with:with: - _arg1 is > undeclared) > > (WinServiceInterface #StartService:with:with: - DWORD is > undeclared) > > (WinServiceInterface #StartService:with:with: - _arg2 is > undeclared) > > (WinServiceInterface #QueryServiceConfig:with:with:with: - > > LPQUERY_SERVICE_CONFIG is undeclared) > > (WinServiceInterface #QueryServiceConfig:with:with:with: - PDWORD is > > undeclared) > > (WinServiceInterface > > #EnumServicesStatus:with:with:with:with:with:with:with: - > > LPENUM_SERVICE_STATUS is undeclared) > > (WinServiceInterface #SetServiceStatus:with: - LPSERVICE_STATUS is > > undeclared) > > (WinServiceInterface #GetServiceDisplayName:with:with:with: > - _arg3 is > > undeclared) (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg4 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg5 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg6 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg7 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg8 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg9 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg10 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg11 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg12 is undeclared) > > (WinServiceInterface #SetServiceObjectSecurity:with:with: - > > PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface > > #QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is > > undeclared) > > Done > > > > > > > > |
RE: ExternalDictionary corrupted in Store?
|
|
Steven,
Others have commented that the workaround they implement is to recompile external interface hierarchies with a post load action in the pundle where they are defined. Note, however, that this problem will also manifest itself when working with an external interface in a browser: if you compile a type definition, then a procedure that uses it, then change the type definition, the procedure will still refer to the old type definition because the change in the type definition is not propagated. Because of both of these problems, what is currently implemented in the DEV versions is that, upon recompilation of a type definition, the hierarchy where the type redefinition occurred is recompiled on the fly. This may seem heavy handed at first. However, with the current compiler and type system implementation we have, I did not see a way to cheaply and accurately infer which methods truly depend on a particular type definition. Another complication to handle would have been the redefinition of the recompiled method by a subclass. In the interest of being comprehensively correct and not too disruptive with DLLCC or Store, this approach was chosen. So that this change has less of an impact on loading performance, a couple small changes were made to speed up loading of packages containing external interfaces by about 20%. From the tests I made, it did not seem that the change had much of a noticeable effect when working on a browser. At any rate, the real issue is that currently there is no distinction between compilation of an external procedure declaration in a method and configuration of the external procedure for run time operation. The idea is that things like the relationship between type references and type declarations should be deferred to the point when the external interface is exercised. Therefore, the long term goal is a better implementation of DLLCC so that there are no such things like stale type references, the current external dictionaries, or class hierarchies that do not behave like Smalltalk. Thanks, Andres. -----Original Message----- From: Steven Kelly [mailto:[hidden email]] Sent: Friday, November 02, 2007 2:04 AM To: Andres Valloud; [hidden email] Subject: RE: ExternalDictionary corrupted in Store? Yes, that makes sense: the procedures are being compiled before the types, so DWORD etc. aren't available. Presumably the solution is twofold: 1) correct the order on load, and 2) also publish in the right order (for older VWs to be able to load correctly). Is 2) implemented in the latest VW dev version? BTW, why aren't we seeing this more? The order in Store appears random, so I'd imagine most ExternalInterface packages would have this problem in at least some procedures. Thanks, Steve > -----Original Message----- > From: Andres Valloud [mailto:[hidden email]] > Sent: 1. marraskuuta 2007 19:53 > To: [hidden email] > Subject: Re: ExternalDictionary corrupted in Store? > > > Steven, > > This issue has been recently rectified in VW. It has to do with the > fact that, upon loading, the order in which type definitions are > compiled has an influence in their final meaning. > > Thanks, > Andres. > > Steven Kelly wrote: > > When I load WinService versions 1.0.9 or earlier from the > public Store > > into VW 7.4.1, its DLLCC code looks right but most of the > procedures > > fail. E.g. try running the following line, which should do nothing > > (unless you have a Windows service called foobar!): > > > > WinServiceInterface new deregisterService: 'foobar' > > > > It gives an "Invalid procedure argument" error, because the > function, > > defined as > > > > void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) > > > > is in the ExternalDictionary as: > > > > void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, LPCSTR DWORD) > > > > i.e. the last parameter has kept the LPCSTR type of the previous > > argument, and changed DWORD from being the type into being the > > parameter name. > > > > Recompiling the class (e.g. by switching to #debug then > back to #full) > > gets rid of the problem. But how can I get that change into > Store? And > > how did it get there in the first place? > > > > The problem is in all versions of WinService before today, > dating back > > to 2004. It looks like the variables listed as undeclared in the > > Transcript when loading are the problems (log below). As a > workaround, > > 1.0.10 adds a postLoadBlock to recompileMethods. Any clues > as to how > > this should be solved properly? > > > > Cheers, > > Steve > > > > Loading WinService . . . > > (WinServiceInterface #StartService:with:with: - _arg1 is > undeclared) > > (WinServiceInterface #StartService:with:with: - DWORD is > undeclared) > > (WinServiceInterface #StartService:with:with: - _arg2 is > undeclared) > > (WinServiceInterface #QueryServiceConfig:with:with:with: - > > LPQUERY_SERVICE_CONFIG is undeclared) (WinServiceInterface > > #QueryServiceConfig:with:with:with: - PDWORD is > > undeclared) > > (WinServiceInterface > > #EnumServicesStatus:with:with:with:with:with:with:with: - > > LPENUM_SERVICE_STATUS is undeclared) (WinServiceInterface > > #SetServiceStatus:with: - LPSERVICE_STATUS is > > undeclared) > > (WinServiceInterface #GetServiceDisplayName:with:with:with: > - _arg3 is > > undeclared) (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg4 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg5 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg6 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg7 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg8 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg9 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg10 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg11 is undeclared) > > (WinServiceInterface > > > #CreateService:with:with:with:with:with:with:with:with:with:wi > th:with:wi > > th: - _arg12 is undeclared) > > (WinServiceInterface #SetServiceObjectSecurity:with:with: - > > PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface > > #QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is > > undeclared) > > Done > > > > > > > > |
Re: ExternalDictionary corrupted in Store?
|
|
In reply to this post by Steven Kelly
Steven Kelly schrieb am 02.11.2007 10:03:
> BTW, why aren't we seeing this more? The order in Store appears random, > so I'd imagine most ExternalInterface packages would have this problem > in at least some procedures. This problem has already surfaced several times during the last year or so. The Registry package and JNIPort both had this issue. You are not alone. ;-) Joachim |
Re: ExternalDictionary corrupted in Store?
|
|
In reply to this post by Steven Kelly
Dear Steve et al,
basic Store uses CTYPE to handle ExternalInterface ordering issues (see #sortForLoading:package:) but StoreGlorp did not set CTYPE when replicating. (Someone, probably reusing a field previously for something else, set this to be stored in column 'version' which is a truly dreadful name for it and probably explains why it went missing.) My fix also seems to have gone missing so I republished it last night to the Cincom OR. It awaits Alan's review. If affected packages were published and then replicated, they would load OK from the DB in which they were published but might not from the DB to which they were replicated. Anyone think this matches what is being seen? Yours faithfully Niall Ross > This problem has already surfaced several times during the last year or > so. The Registry package and JNIPort both had this issue. You are not > alone. ;-) >Yes, that makes sense: the procedures are being compiled before the >types, so DWORD etc. aren't available. Presumably the solution is >twofold: 1) correct the order on load, and 2) also publish in the right >order (for older VWs to be able to load correctly). Is 2) implemented in >the latest VW dev version? > >BTW, why aren't we seeing this more? The order in Store appears random, >so I'd imagine most ExternalInterface packages would have this problem >in at least some procedures. > >Thanks, >Steve > > > >>-----Original Message----- >>From: Andres Valloud [mailto:[hidden email]] >>Sent: 1. marraskuuta 2007 19:53 >>To: [hidden email] >>Subject: Re: ExternalDictionary corrupted in Store? >> >> >>Steven, >> >>This issue has been recently rectified in VW. It has to do with the >>fact that, upon loading, the order in which type definitions are >>compiled has an influence in their final meaning. >> >>Thanks, >>Andres. >> >>Steven Kelly wrote: >> >> >>>When I load WinService versions 1.0.9 or earlier from the >>> >>> >>public Store >> >> >>>into VW 7.4.1, its DLLCC code looks right but most of the >>> >>> >>procedures >> >> >>>fail. E.g. try running the following line, which should do nothing >>>(unless you have a Windows service called foobar!): >>> >>> WinServiceInterface new deregisterService: 'foobar' >>> >>>It gives an "Invalid procedure argument" error, because the >>> >>> >>function, >> >> >>>defined as >>> >>> void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) >>> >>>is in the ExternalDictionary as: >>> >>> void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, LPCSTR DWORD) >>> >>>i.e. the last parameter has kept the LPCSTR type of the previous >>>argument, and changed DWORD from being the type into being the >>>parameter name. >>> >>>Recompiling the class (e.g. by switching to #debug then >>> >>> >>back to #full) >> >> >>>gets rid of the problem. But how can I get that change into >>> >>> >>Store? And >> >> >>>how did it get there in the first place? >>> >>>The problem is in all versions of WinService before today, >>> >>> >>dating back >> >> >>>to 2004. It looks like the variables listed as undeclared in the >>>Transcript when loading are the problems (log below). As a >>> >>> >>workaround, >> >> >>>1.0.10 adds a postLoadBlock to recompileMethods. Any clues >>> >>> >>as to how >> >> >>>this should be solved properly? >>> >>>Cheers, >>>Steve >>> >>>Loading WinService . . . >>>(WinServiceInterface #StartService:with:with: - _arg1 is >>> >>> >>undeclared) >> >> >>>(WinServiceInterface #StartService:with:with: - DWORD is >>> >>> >>undeclared) >> >> >>>(WinServiceInterface #StartService:with:with: - _arg2 is >>> >>> >>undeclared) >> >> >>>(WinServiceInterface #QueryServiceConfig:with:with:with: - >>>LPQUERY_SERVICE_CONFIG is undeclared) >>>(WinServiceInterface #QueryServiceConfig:with:with:with: - PDWORD is >>>undeclared) >>>(WinServiceInterface >>>#EnumServicesStatus:with:with:with:with:with:with:with: - >>>LPENUM_SERVICE_STATUS is undeclared) >>>(WinServiceInterface #SetServiceStatus:with: - LPSERVICE_STATUS is >>>undeclared) >>>(WinServiceInterface #GetServiceDisplayName:with:with:with: >>> >>> >>- _arg3 is >> >> >>>undeclared) (WinServiceInterface >>> >>> >>> >>#CreateService:with:with:with:with:with:with:with:with:with:wi >>th:with:wi >> >> >>>th: - _arg4 is undeclared) >>>(WinServiceInterface >>> >>> >>> >>#CreateService:with:with:with:with:with:with:with:with:with:wi >>th:with:wi >> >> >>>th: - _arg5 is undeclared) >>>(WinServiceInterface >>> >>> >>> >>#CreateService:with:with:with:with:with:with:with:with:with:wi >>th:with:wi >> >> >>>th: - _arg6 is undeclared) >>>(WinServiceInterface >>> >>> >>> >>#CreateService:with:with:with:with:with:with:with:with:with:wi >>th:with:wi >> >> >>>th: - _arg7 is undeclared) >>>(WinServiceInterface >>> >>> >>> >>#CreateService:with:with:with:with:with:with:with:with:with:wi >>th:with:wi >> >> >>>th: - _arg8 is undeclared) >>>(WinServiceInterface >>> >>> >>> >>#CreateService:with:with:with:with:with:with:with:with:with:wi >>th:with:wi >> >> >>>th: - _arg9 is undeclared) >>>(WinServiceInterface >>> >>> >>> >>#CreateService:with:with:with:with:with:with:with:with:with:wi >>th:with:wi >> >> >>>th: - _arg10 is undeclared) >>>(WinServiceInterface >>> >>> >>> >>#CreateService:with:with:with:with:with:with:with:with:with:wi >>th:with:wi >> >> >>>th: - _arg11 is undeclared) >>>(WinServiceInterface >>> >>> >>> >>#CreateService:with:with:with:with:with:with:with:with:with:wi >>th:with:wi >> >> >>>th: - _arg12 is undeclared) >>>(WinServiceInterface #SetServiceObjectSecurity:with:with: - >>>PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface >>>#QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is >>>undeclared) >>>Done >>> >>> >>> >>> >>> >> >> > > > > > |
Re: ExternalDictionary corrupted in Store?
|
|
Hmm, I thought that once upon a time I had looked at that
fairly carefully and decided that the CTYPE stuff really wasn't used for
anything that made a difference. I think the only thing that it does is
move all the CTYPE methods to the beginning. Which means they'll come
before other methods, but I would expect that the ordering constraints
are between those methods, rather than between them and other methods.
But your changes look fine anyway.
At 01:42 PM 11/6/2007, Niall Ross wrote: Dear Steve et al, --
Alan Knight [|], Cincom Smalltalk Development
|
Re: ExternalDictionary corrupted in Store?
|
|
Dear Alan,
my understanding of the code (and my experience - I saw load failures of the same kind as the one Steve reports when CTYPE was not set) is that it is precisely the C _types_ (only) that are front-sorted, so that, by Steve's analysis: > Yes, that makes sense: the procedures are being compiled before the > types, so DWORD etc. aren't available. having CTYPEs set would fix his problem. If, that is, the problem arose through StoreGlorp replication dropping the CTYPEs; I know no reason why direct publishing via StoreBase should lose them (noting that I have not reviewed this code since 7.4). Steve, it would be interesting to know - whether you can say that the problem you saw did or could, or else could not, relate to versions that were replicated? and, independently of that, - whether the not-loaded-first type pragma'd method has CTYPE set or not in the database for the problem version. Yours faithfully Niall Ross > Hmm, I thought that once upon a time I had looked at that fairly > carefully and decided that the CTYPE stuff really wasn't used for > anything that made a difference. I think the only thing that it does > is move all the CTYPE methods to the beginning. Which means they'll > come before other methods, but I would expect that the ordering > constraints are between those methods, rather than between them and > other methods. But your changes look fine anyway. > > At 01:42 PM 11/6/2007, Niall Ross wrote: > >> Dear Steve et al, >> basic Store uses CTYPE to handle ExternalInterface ordering issues >> (see #sortForLoading:package:) but StoreGlorp did not set CTYPE when >> replicating. (Someone, probably reusing a field previously for >> something else, set this to be stored in column 'version' which is a >> truly dreadful name for it and probably explains why it went missing.) >> >> My fix also seems to have gone missing so I republished it last night >> to the Cincom OR. It awaits Alan's review. >> >> If affected packages were published and then replicated, they would >> load OK from the DB in which they were published but might not from >> the DB to which they were replicated. >> >> Anyone think this matches what is being seen? >> >> Yours faithfully >> Niall Ross >> >> > This problem has already surfaced several times during the last year or >> > so. The Registry package and JNIPort both had this issue. You are not >> > alone. ;-) >> >>> Yes, that makes sense: the procedures are being compiled before the >>> types, so DWORD etc. aren't available. Presumably the solution is >>> twofold: 1) correct the order on load, and 2) also publish in the right >>> order (for older VWs to be able to load correctly). Is 2) implemented in >>> the latest VW dev version? >>> >>> BTW, why aren't we seeing this more? The order in Store appears random, >>> so I'd imagine most ExternalInterface packages would have this problem >>> in at least some procedures. >>> Thanks, >>> Steve >>> >>> >>> >>>> -----Original Message----- >>>> From: Andres Valloud [ mailto:[hidden email]] Sent: 1. >>>> marraskuuta 2007 19:53 >>>> To: [hidden email] >>>> Subject: Re: ExternalDictionary corrupted in Store? >>>> >>>> >>>> Steven, >>>> >>>> This issue has been recently rectified in VW. It has to do with >>>> the fact that, upon loading, the order in which type definitions >>>> are compiled has an influence in their final meaning. >>>> >>>> Thanks, >>>> Andres. >>>> >>>> Steven Kelly wrote: >>>> >>>> >>>>> When I load WinService versions 1.0.9 or earlier from the >>>> >>>> public Store >>>> >>>>> into VW 7.4.1, its DLLCC code looks right but most of the >>>> >>>> procedures >>>> >>>>> fail. E.g. try running the following line, which should do nothing >>>>> (unless you have a Windows service called foobar!): >>>>> >>>>> WinServiceInterface new deregisterService: 'foobar' >>>>> >>>>> It gives an "Invalid procedure argument" error, because the >>>> >>>> function, >>>> >>>>> defined as >>>>> >>>>> void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) >>>>> >>>>> is in the ExternalDictionary as: >>>>> >>>>> void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, LPCSTR DWORD) >>>>> >>>>> i.e. the last parameter has kept the LPCSTR type of the previous >>>>> argument, and changed DWORD from being the type into being the >>>>> parameter name. >>>>> >>>>> Recompiling the class (e.g. by switching to #debug then >>>> >>>> back to #full) >>>> >>>>> gets rid of the problem. But how can I get that change into >>>> >>>> Store? And >>>> >>>>> how did it get there in the first place? >>>>> >>>>> The problem is in all versions of WinService before today, >>>> >>>> dating back >>>> >>>>> to 2004. It looks like the variables listed as undeclared in the >>>>> Transcript when loading are the problems (log below). As a >>>> >>>> workaround, >>>> >>>>> 1.0.10 adds a postLoadBlock to recompileMethods. Any clues >>>> >>>> as to how >>>> >>>>> this should be solved properly? >>>>> >>>>> Cheers, >>>>> Steve >>>>> >>>>> Loading WinService . . . >>>>> (WinServiceInterface #StartService:with:with: - _arg1 is >>>> >>>> undeclared) >>>> >>>> >>>>> (WinServiceInterface #StartService:with:with: - DWORD is >>>> >>>> undeclared) >>>> >>>> >>>>> (WinServiceInterface #StartService:with:with: - _arg2 is >>>> >>>> undeclared) >>>> >>>> >>>>> (WinServiceInterface #QueryServiceConfig:with:with:with: - >>>>> LPQUERY_SERVICE_CONFIG is undeclared) >>>>> (WinServiceInterface #QueryServiceConfig:with:with:with: - PDWORD is >>>>> undeclared) >>>>> (WinServiceInterface >>>>> #EnumServicesStatus:with:with:with:with:with:with:with: - >>>>> LPENUM_SERVICE_STATUS is undeclared) >>>>> (WinServiceInterface #SetServiceStatus:with: - LPSERVICE_STATUS is >>>>> undeclared) >>>>> (WinServiceInterface #GetServiceDisplayName:with:with:with: >>>> >>>> - _arg3 is >>>> >>>> >>>>> undeclared) (WinServiceInterface >>>>> >>>>> >>>> >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>> th:with:wi >>>> >>>> >>>>> th: - _arg4 is undeclared) >>>>> (WinServiceInterface >>>>> >>>>> >>>> >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>> th:with:wi >>>> >>>> >>>>> th: - _arg5 is undeclared) >>>>> (WinServiceInterface >>>>> >>>>> >>>> >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>> th:with:wi >>>> >>>> >>>>> th: - _arg6 is undeclared) >>>>> (WinServiceInterface >>>>> >>>>> >>>> >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>> th:with:wi >>>> >>>> >>>>> th: - _arg7 is undeclared) >>>>> (WinServiceInterface >>>>> >>>>> >>>> >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>> th:with:wi >>>> >>>> >>>>> th: - _arg8 is undeclared) >>>>> (WinServiceInterface >>>>> >>>>> >>>> >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>> th:with:wi >>>> >>>> >>>>> th: - _arg9 is undeclared) >>>>> (WinServiceInterface >>>>> >>>>> >>>> >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>> th:with:wi >>>> >>>> >>>>> th: - _arg10 is undeclared) >>>>> (WinServiceInterface >>>>> >>>>> >>>> >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>> th:with:wi >>>> >>>> >>>>> th: - _arg11 is undeclared) >>>>> (WinServiceInterface >>>>> >>>>> >>>> >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>> th:with:wi >>>> >>>> >>>>> th: - _arg12 is undeclared) >>>>> (WinServiceInterface #SetServiceObjectSecurity:with:with: - >>>>> PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface >>>>> #QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is >>>>> undeclared) Done >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> > > -- > Alan Knight [|], Cincom Smalltalk Development > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk |
RE: ExternalDictionary corrupted in Store?
|
|
In reply to this post by Steven Kelly
Everything in the Open Repository seems to have been replicated by Alan
with the switch to the new server. I can't connect at the moment to confirm that (it seems to be down), but that's my recollection. The problems I've seen have only happened after that replication. I think others have seen problems before, but maybe they were replicating their packages? I don't know how to check whether CTYPE is set or not in the database. The external dictionary when loaded contains typedefs and at least some of the procedures. After running recompileMethods, it only contains typedefs (at least they are all that is shown in the normal view in Trippy). HTH, Steve > -----Original Message----- > From: Niall Ross [mailto:[hidden email]] > Sent: 8. marraskuuta 2007 17:28 > To: Alan Knight > Cc: Steven Kelly; Andres Valloud; [hidden email]; Joachim Geidel > Subject: Re: ExternalDictionary corrupted in Store? > > > Dear Alan, > my understanding of the code (and my experience - I saw load > failures of the same kind as the one Steve reports when CTYPE was not > set) is that it is precisely the C _types_ (only) that are > front-sorted, > so that, by Steve's analysis: > > > Yes, that makes sense: the procedures are being compiled > before the > types, so DWORD etc. aren't available. > > having CTYPEs set would fix his problem. > > If, that is, the problem arose through StoreGlorp replication > dropping > the CTYPEs; I know no reason why direct publishing via > StoreBase should > lose them (noting that I have not reviewed this code since > 7.4). Steve, > it would be interesting to know > - whether you can say that the problem you saw did or could, > or else could not, relate to versions that were > replicated? and, independently of that, > - whether the not-loaded-first type pragma'd method has > CTYPE set or not in the database for the problem version. > > Yours faithfully > Niall Ross > > > Hmm, I thought that once upon a time I had looked at that fairly > > carefully and decided that the CTYPE stuff really wasn't used for > > anything that made a difference. I think the only thing > that it does > > is move all the CTYPE methods to the beginning. Which means they'll > > come before other methods, but I would expect that the ordering > > constraints are between those methods, rather than between them and > > other methods. But your changes look fine anyway. > > > > At 01:42 PM 11/6/2007, Niall Ross wrote: > > > >> Dear Steve et al, > >> basic Store uses CTYPE to handle ExternalInterface > ordering issues > >> (see #sortForLoading:package:) but StoreGlorp did not set > CTYPE when > >> replicating. (Someone, probably reusing a field previously for > >> something else, set this to be stored in column 'version' > which is a > >> truly dreadful name for it and probably explains why it > went missing.) > >> > >> My fix also seems to have gone missing so I republished it > last night > >> to the Cincom OR. It awaits Alan's review. > >> > >> If affected packages were published and then replicated, they would > >> load OK from the DB in which they were published but might > not from > >> the DB to which they were replicated. > >> > >> Anyone think this matches what is being seen? > >> > >> Yours faithfully > >> Niall Ross > >> > >> > This problem has already surfaced several times during the last > >> > year or so. The Registry package and JNIPort both had > this issue. > >> > You are not alone. ;-) > >> > >>> Yes, that makes sense: the procedures are being compiled > before the > >>> types, so DWORD etc. aren't available. Presumably the solution is > >>> twofold: 1) correct the order on load, and 2) also publish in the > >>> right order (for older VWs to be able to load correctly). Is 2) > >>> implemented in the latest VW dev version? > >>> > >>> BTW, why aren't we seeing this more? The order in Store appears > >>> random, so I'd imagine most ExternalInterface packages would have > >>> this problem in at least some procedures. Thanks, > >>> Steve > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Andres Valloud [ mailto:[hidden email]] Sent: 1. > >>>> marraskuuta 2007 19:53 > >>>> To: [hidden email] > >>>> Subject: Re: ExternalDictionary corrupted in Store? > >>>> > >>>> > >>>> Steven, > >>>> > >>>> This issue has been recently rectified in VW. It has to do with > >>>> the fact that, upon loading, the order in which type definitions > >>>> are compiled has an influence in their final meaning. > >>>> > >>>> Thanks, > >>>> Andres. > >>>> > >>>> Steven Kelly wrote: > >>>> > >>>> > >>>>> When I load WinService versions 1.0.9 or earlier from the > >>>> > >>>> public Store > >>>> > >>>>> into VW 7.4.1, its DLLCC code looks right but most of the > >>>> > >>>> procedures > >>>> > >>>>> fail. E.g. try running the following line, which should > do nothing > >>>>> (unless you have a Windows service called foobar!): > >>>>> > >>>>> WinServiceInterface new deregisterService: 'foobar' > >>>>> > >>>>> It gives an "Invalid procedure argument" error, because the > >>>> > >>>> function, > >>>> > >>>>> defined as > >>>>> > >>>>> void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) > >>>>> > >>>>> is in the ExternalDictionary as: > >>>>> > >>>>> void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, > LPCSTR DWORD) > >>>>> > >>>>> i.e. the last parameter has kept the LPCSTR type of the previous > >>>>> argument, and changed DWORD from being the type into being the > >>>>> parameter name. > >>>>> > >>>>> Recompiling the class (e.g. by switching to #debug then > >>>> > >>>> back to #full) > >>>> > >>>>> gets rid of the problem. But how can I get that change into > >>>> > >>>> Store? And > >>>> > >>>>> how did it get there in the first place? > >>>>> > >>>>> The problem is in all versions of WinService before today, > >>>> > >>>> dating back > >>>> > >>>>> to 2004. It looks like the variables listed as > undeclared in the > >>>>> Transcript when loading are the problems (log below). As a > >>>> > >>>> workaround, > >>>> > >>>>> 1.0.10 adds a postLoadBlock to recompileMethods. Any clues > >>>> > >>>> as to how > >>>> > >>>>> this should be solved properly? > >>>>> > >>>>> Cheers, > >>>>> Steve > >>>>> > >>>>> Loading WinService . . . > >>>>> (WinServiceInterface #StartService:with:with: - _arg1 is > >>>> > >>>> undeclared) > >>>> > >>>> > >>>>> (WinServiceInterface #StartService:with:with: - DWORD is > >>>> > >>>> undeclared) > >>>> > >>>> > >>>>> (WinServiceInterface #StartService:with:with: - _arg2 is > >>>> > >>>> undeclared) > >>>> > >>>> > >>>>> (WinServiceInterface #QueryServiceConfig:with:with:with: - > >>>>> LPQUERY_SERVICE_CONFIG is undeclared) (WinServiceInterface > >>>>> #QueryServiceConfig:with:with:with: - PDWORD is > >>>>> undeclared) > >>>>> (WinServiceInterface > >>>>> #EnumServicesStatus:with:with:with:with:with:with:with: - > >>>>> LPENUM_SERVICE_STATUS is undeclared) > >>>>> (WinServiceInterface #SetServiceStatus:with: - > LPSERVICE_STATUS is > >>>>> undeclared) > >>>>> (WinServiceInterface #GetServiceDisplayName:with:with:with: > >>>> > >>>> - _arg3 is > >>>> > >>>> > >>>>> undeclared) (WinServiceInterface > >>>>> > >>>>> > >>>> > >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi > >>>> th:with:wi > >>>> > >>>> > >>>>> th: - _arg4 is undeclared) > >>>>> (WinServiceInterface > >>>>> > >>>>> > >>>> > >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi > >>>> th:with:wi > >>>> > >>>> > >>>>> th: - _arg5 is undeclared) > >>>>> (WinServiceInterface > >>>>> > >>>>> > >>>> > >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi > >>>> th:with:wi > >>>> > >>>> > >>>>> th: - _arg6 is undeclared) > >>>>> (WinServiceInterface > >>>>> > >>>>> > >>>> > >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi > >>>> th:with:wi > >>>> > >>>> > >>>>> th: - _arg7 is undeclared) > >>>>> (WinServiceInterface > >>>>> > >>>>> > >>>> > >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi > >>>> th:with:wi > >>>> > >>>> > >>>>> th: - _arg8 is undeclared) > >>>>> (WinServiceInterface > >>>>> > >>>>> > >>>> > >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi > >>>> th:with:wi > >>>> > >>>> > >>>>> th: - _arg9 is undeclared) > >>>>> (WinServiceInterface > >>>>> > >>>>> > >>>> > >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi > >>>> th:with:wi > >>>> > >>>> > >>>>> th: - _arg10 is undeclared) > >>>>> (WinServiceInterface > >>>>> > >>>>> > >>>> > >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi > >>>> th:with:wi > >>>> > >>>> > >>>>> th: - _arg11 is undeclared) > >>>>> (WinServiceInterface > >>>>> > >>>>> > >>>> > >>>> #CreateService:with:with:with:with:with:with:with:with:with:wi > >>>> th:with:wi > >>>> > >>>> > >>>>> th: - _arg12 is undeclared) > >>>>> (WinServiceInterface #SetServiceObjectSecurity:with:with: - > >>>>> PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface > >>>>> #QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is > >>>>> undeclared) Done > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > -- > > Alan Knight [|], Cincom Smalltalk Development > > [hidden email] > > [hidden email] > > http://www.cincom.com/smalltalk > > > > |
Re: ExternalDictionary corrupted in Store?
|
|
In reply to this post by Niall Ross
OK, I tried to regenerate that information in the public
Store. See if that makes a difference.
At 10:28 AM 11/8/2007, Niall Ross wrote: Dear Alan, --
Alan Knight [|], Cincom Smalltalk Development
|
RE: ExternalDictionary corrupted in Store?
|
|
In reply to this post by Steven Kelly
Thanks Alan! That
did the trick for WinService 1.0.9 (the last version without the postLoadBlock
that rebuilds the external dictionary anyway)
Steve
--
Alan Knight [|], Cincom Smalltalk Development
|
Re: ExternalDictionary corrupted in Store?
|
|
In reply to this post by Steven Kelly
Dear Steve,
> I don't know how to check whether CTYPE is set or not in the database. Now all is working, there is probably no need for you to check. However just FYI, in case others need to examine their replicated packages: You need to view the 'version' column of a method with pragma defining a C type. If it holds the value 'CTYPE', all is well; if not, replicate is losing them. If you don't have a convenient db-viewing utility then load a StoreGlorp version that reads CTYPE, i.e. 2.4.58 CS12.NFR.12 or later (or an earlier ... CS*.NFR.* will also work). You need StoreDescriptorSystem>>descriptorForStoreMethod: to include (aDescriptor newMapping: DirectMapping) from: #version to: (table fieldNamed: 'version'). Then invoke Store > Store Workbook, edit an expression to read the chosen method (maybe read its package and navigate to it is easier) and see what is in its 'version' instvar. Yours faithfully Niall Ross >Everything in the Open Repository seems to have been replicated by Alan >with the switch to the new server. I can't connect at the moment to >confirm that (it seems to be down), but that's my recollection. The >problems I've seen have only happened after that replication. I think >others have seen problems before, but maybe they were replicating their >packages? > >I don't know how to check whether CTYPE is set or not in the database. >The external dictionary when loaded contains typedefs and at least some >of the procedures. After running recompileMethods, it only contains >typedefs (at least they are all that is shown in the normal view in >Trippy). > >HTH, >Steve > > > >>-----Original Message----- >>From: Niall Ross [mailto:[hidden email]] >>Sent: 8. marraskuuta 2007 17:28 >>To: Alan Knight >>Cc: Steven Kelly; Andres Valloud; [hidden email]; Joachim Geidel >>Subject: Re: ExternalDictionary corrupted in Store? >> >> >>Dear Alan, >> my understanding of the code (and my experience - I saw load >>failures of the same kind as the one Steve reports when CTYPE was not >>set) is that it is precisely the C _types_ (only) that are >>front-sorted, >>so that, by Steve's analysis: >> >> > Yes, that makes sense: the procedures are being compiled >>before the > types, so DWORD etc. aren't available. >> >>having CTYPEs set would fix his problem. >> >>If, that is, the problem arose through StoreGlorp replication >>dropping >>the CTYPEs; I know no reason why direct publishing via >>StoreBase should >>lose them (noting that I have not reviewed this code since >>7.4). Steve, >>it would be interesting to know >> - whether you can say that the problem you saw did or could, >> or else could not, relate to versions that were >>replicated? and, independently of that, >> - whether the not-loaded-first type pragma'd method has >> CTYPE set or not in the database for the problem version. >> >> Yours faithfully >> Niall Ross >> >> >> >>>Hmm, I thought that once upon a time I had looked at that fairly >>>carefully and decided that the CTYPE stuff really wasn't used for >>>anything that made a difference. I think the only thing >>> >>> >>that it does >> >> >>>is move all the CTYPE methods to the beginning. Which means they'll >>>come before other methods, but I would expect that the ordering >>>constraints are between those methods, rather than between them and >>>other methods. But your changes look fine anyway. >>> >>>At 01:42 PM 11/6/2007, Niall Ross wrote: >>> >>> >>> >>>>Dear Steve et al, >>>> basic Store uses CTYPE to handle ExternalInterface >>>> >>>> >>ordering issues >> >> >>>>(see #sortForLoading:package:) but StoreGlorp did not set >>>> >>>> >>CTYPE when >> >> >>>>replicating. (Someone, probably reusing a field previously for >>>>something else, set this to be stored in column 'version' >>>> >>>> >>which is a >> >> >>>>truly dreadful name for it and probably explains why it >>>> >>>> >>went missing.) >> >> >>>>My fix also seems to have gone missing so I republished it >>>> >>>> >>last night >> >> >>>>to the Cincom OR. It awaits Alan's review. >>>> >>>>If affected packages were published and then replicated, they would >>>>load OK from the DB in which they were published but might >>>> >>>> >>not from >> >> >>>>the DB to which they were replicated. >>>> >>>>Anyone think this matches what is being seen? >>>> >>>> Yours faithfully >>>> Niall Ross >>>> >>>> >>>> >>>>>This problem has already surfaced several times during the last >>>>>year or so. The Registry package and JNIPort both had >>>>> >>>>> >>this issue. >> >> >>>>>You are not alone. ;-) >>>>> >>>>> >>>>>Yes, that makes sense: the procedures are being compiled >>>>> >>>>> >>before the >> >> >>>>>types, so DWORD etc. aren't available. Presumably the solution is >>>>>twofold: 1) correct the order on load, and 2) also publish in the >>>>>right order (for older VWs to be able to load correctly). Is 2) >>>>>implemented in the latest VW dev version? >>>>> >>>>>BTW, why aren't we seeing this more? The order in Store appears >>>>>random, so I'd imagine most ExternalInterface packages would have >>>>>this problem in at least some procedures. Thanks, >>>>>Steve >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Andres Valloud [ mailto:[hidden email]] Sent: 1. >>>>>>marraskuuta 2007 19:53 >>>>>>To: [hidden email] >>>>>>Subject: Re: ExternalDictionary corrupted in Store? >>>>>> >>>>>> >>>>>>Steven, >>>>>> >>>>>>This issue has been recently rectified in VW. It has to do with >>>>>>the fact that, upon loading, the order in which type definitions >>>>>>are compiled has an influence in their final meaning. >>>>>> >>>>>>Thanks, >>>>>>Andres. >>>>>> >>>>>>Steven Kelly wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>When I load WinService versions 1.0.9 or earlier from the >>>>>>> >>>>>>> >>>>>>public Store >>>>>> >>>>>> >>>>>> >>>>>>>into VW 7.4.1, its DLLCC code looks right but most of the >>>>>>> >>>>>>> >>>>>>procedures >>>>>> >>>>>> >>>>>> >>>>>>>fail. E.g. try running the following line, which should >>>>>>> >>>>>>> >>do nothing >> >> >>>>>>>(unless you have a Windows service called foobar!): >>>>>>> >>>>>>> WinServiceInterface new deregisterService: 'foobar' >>>>>>> >>>>>>>It gives an "Invalid procedure argument" error, because the >>>>>>> >>>>>>> >>>>>>function, >>>>>> >>>>>> >>>>>> >>>>>>>defined as >>>>>>> >>>>>>> void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) >>>>>>> >>>>>>>is in the ExternalDictionary as: >>>>>>> >>>>>>> void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, >>>>>>> >>>>>>> >>LPCSTR DWORD) >> >> >>>>>>>i.e. the last parameter has kept the LPCSTR type of the previous >>>>>>>argument, and changed DWORD from being the type into being the >>>>>>>parameter name. >>>>>>> >>>>>>>Recompiling the class (e.g. by switching to #debug then >>>>>>> >>>>>>> >>>>>>back to #full) >>>>>> >>>>>> >>>>>> >>>>>>>gets rid of the problem. But how can I get that change into >>>>>>> >>>>>>> >>>>>>Store? And >>>>>> >>>>>> >>>>>> >>>>>>>how did it get there in the first place? >>>>>>> >>>>>>>The problem is in all versions of WinService before today, >>>>>>> >>>>>>> >>>>>>dating back >>>>>> >>>>>> >>>>>> >>>>>>>to 2004. It looks like the variables listed as >>>>>>> >>>>>>> >>undeclared in the >> >> >>>>>>>Transcript when loading are the problems (log below). As a >>>>>>> >>>>>>> >>>>>>workaround, >>>>>> >>>>>> >>>>>> >>>>>>>1.0.10 adds a postLoadBlock to recompileMethods. Any clues >>>>>>> >>>>>>> >>>>>>as to how >>>>>> >>>>>> >>>>>> >>>>>>>this should be solved properly? >>>>>>> >>>>>>>Cheers, >>>>>>>Steve >>>>>>> >>>>>>>Loading WinService . . . >>>>>>>(WinServiceInterface #StartService:with:with: - _arg1 is >>>>>>> >>>>>>> >>>>>>undeclared) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>(WinServiceInterface #StartService:with:with: - DWORD is >>>>>>> >>>>>>> >>>>>>undeclared) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>(WinServiceInterface #StartService:with:with: - _arg2 is >>>>>>> >>>>>>> >>>>>>undeclared) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>(WinServiceInterface #QueryServiceConfig:with:with:with: - >>>>>>>LPQUERY_SERVICE_CONFIG is undeclared) (WinServiceInterface >>>>>>>#QueryServiceConfig:with:with:with: - PDWORD is >>>>>>>undeclared) >>>>>>>(WinServiceInterface >>>>>>>#EnumServicesStatus:with:with:with:with:with:with:with: - >>>>>>>LPENUM_SERVICE_STATUS is undeclared) >>>>>>>(WinServiceInterface #SetServiceStatus:with: - >>>>>>> >>>>>>> >>LPSERVICE_STATUS is >> >> >>>>>>>undeclared) >>>>>>>(WinServiceInterface #GetServiceDisplayName:with:with:with: >>>>>>> >>>>>>> >>>>>>- _arg3 is >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>#CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>>th:with:wi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>th: - _arg4 is undeclared) >>>>>>>(WinServiceInterface >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>#CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>>th:with:wi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>th: - _arg5 is undeclared) >>>>>>>(WinServiceInterface >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>#CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>>th:with:wi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>th: - _arg6 is undeclared) >>>>>>>(WinServiceInterface >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>#CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>>th:with:wi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>th: - _arg7 is undeclared) >>>>>>>(WinServiceInterface >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>#CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>>th:with:wi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>th: - _arg8 is undeclared) >>>>>>>(WinServiceInterface >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>#CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>>th:with:wi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>th: - _arg9 is undeclared) >>>>>>>(WinServiceInterface >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>#CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>>th:with:wi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>th: - _arg10 is undeclared) >>>>>>>(WinServiceInterface >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>#CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>>th:with:wi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>th: - _arg11 is undeclared) >>>>>>>(WinServiceInterface >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>#CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>>th:with:wi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>th: - _arg12 is undeclared) >>>>>>>(WinServiceInterface #SetServiceObjectSecurity:with:with: - >>>>>>>PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface >>>>>>>#QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is >>>>>>>undeclared) Done >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>-- >>>Alan Knight [|], Cincom Smalltalk Development >>>[hidden email] >>>[hidden email] >>>http://www.cincom.com/smalltalk >>> >>> >> >> >> >> > > > > > |
Re: ExternalDictionary corrupted in Store?
|
|
In reply to this post by Niall Ross
Niall,
Would you mind verifying the VW build you saw this problem in before the CTYPE was set? Thanks, Andres. Niall Ross wrote: > Dear Alan, > my understanding of the code (and my experience - I saw load > failures of the same kind as the one Steve reports when CTYPE was not > set) is that it is precisely the C _types_ (only) that are > front-sorted, so that, by Steve's analysis: > > > Yes, that makes sense: the procedures are being compiled before the > > types, so DWORD etc. aren't available. > > having CTYPEs set would fix his problem. > > If, that is, the problem arose through StoreGlorp replication dropping > the CTYPEs; I know no reason why direct publishing via StoreBase > should lose them (noting that I have not reviewed this code since > 7.4). Steve, it would be interesting to know > - whether you can say that the problem you saw did or could, > or else could not, relate to versions that were replicated? > and, independently of that, > - whether the not-loaded-first type pragma'd method has > CTYPE set or not in the database for the problem version. > > Yours faithfully > Niall Ross > >> Hmm, I thought that once upon a time I had looked at that fairly >> carefully and decided that the CTYPE stuff really wasn't used for >> anything that made a difference. I think the only thing that it does >> is move all the CTYPE methods to the beginning. Which means they'll >> come before other methods, but I would expect that the ordering >> constraints are between those methods, rather than between them and >> other methods. But your changes look fine anyway. >> >> At 01:42 PM 11/6/2007, Niall Ross wrote: >> >>> Dear Steve et al, >>> basic Store uses CTYPE to handle ExternalInterface ordering >>> issues (see #sortForLoading:package:) but StoreGlorp did not set >>> CTYPE when replicating. (Someone, probably reusing a field >>> previously for something else, set this to be stored in column >>> 'version' which is a truly dreadful name for it and probably >>> explains why it went missing.) >>> >>> My fix also seems to have gone missing so I republished it last >>> night to the Cincom OR. It awaits Alan's review. >>> >>> If affected packages were published and then replicated, they would >>> load OK from the DB in which they were published but might not from >>> the DB to which they were replicated. >>> >>> Anyone think this matches what is being seen? >>> >>> Yours faithfully >>> Niall Ross >>> >>> > This problem has already surfaced several times during the last >>> year or >>> > so. The Registry package and JNIPort both had this issue. You are not >>> > alone. ;-) >>> >>>> Yes, that makes sense: the procedures are being compiled before the >>>> types, so DWORD etc. aren't available. Presumably the solution is >>>> twofold: 1) correct the order on load, and 2) also publish in the >>>> right >>>> order (for older VWs to be able to load correctly). Is 2) >>>> implemented in >>>> the latest VW dev version? >>>> >>>> BTW, why aren't we seeing this more? The order in Store appears >>>> random, >>>> so I'd imagine most ExternalInterface packages would have this problem >>>> in at least some procedures. >>>> Thanks, >>>> Steve >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Andres Valloud [ mailto:[hidden email]] Sent: 1. >>>>> marraskuuta 2007 19:53 >>>>> To: [hidden email] >>>>> Subject: Re: ExternalDictionary corrupted in Store? >>>>> >>>>> >>>>> Steven, >>>>> >>>>> This issue has been recently rectified in VW. It has to do with >>>>> the fact that, upon loading, the order in which type definitions >>>>> are compiled has an influence in their final meaning. >>>>> >>>>> Thanks, >>>>> Andres. >>>>> >>>>> Steven Kelly wrote: >>>>> >>>>>> When I load WinService versions 1.0.9 or earlier from the >>>>> >>>>> public Store >>>>>> into VW 7.4.1, its DLLCC code looks right but most of the >>>>> >>>>> procedures >>>>>> fail. E.g. try running the following line, which should do >>>>>> nothing (unless you have a Windows service called foobar!): >>>>>> >>>>>> WinServiceInterface new deregisterService: 'foobar' >>>>>> >>>>>> It gives an "Invalid procedure argument" error, because the >>>>> >>>>> function, >>>>>> defined as >>>>>> >>>>>> void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) >>>>>> >>>>>> is in the ExternalDictionary as: >>>>>> >>>>>> void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, LPCSTR DWORD) >>>>>> >>>>>> i.e. the last parameter has kept the LPCSTR type of the previous >>>>>> argument, and changed DWORD from being the type into being the >>>>>> parameter name. >>>>>> >>>>>> Recompiling the class (e.g. by switching to #debug then >>>>> >>>>> back to #full) >>>>>> gets rid of the problem. But how can I get that change into >>>>> >>>>> Store? And >>>>>> how did it get there in the first place? >>>>>> >>>>>> The problem is in all versions of WinService before today, >>>>> >>>>> dating back >>>>>> to 2004. It looks like the variables listed as undeclared in the >>>>>> Transcript when loading are the problems (log below). As a >>>>> >>>>> workaround, >>>>>> 1.0.10 adds a postLoadBlock to recompileMethods. Any clues >>>>> >>>>> as to how >>>>>> this should be solved properly? >>>>>> >>>>>> Cheers, >>>>>> Steve >>>>>> >>>>>> Loading WinService . . . >>>>>> (WinServiceInterface #StartService:with:with: - _arg1 is >>>>> >>>>> undeclared) >>>>>> (WinServiceInterface #StartService:with:with: - DWORD is >>>>> >>>>> undeclared) >>>>>> (WinServiceInterface #StartService:with:with: - _arg2 is >>>>> >>>>> undeclared) >>>>>> (WinServiceInterface #QueryServiceConfig:with:with:with: - >>>>>> LPQUERY_SERVICE_CONFIG is undeclared) (WinServiceInterface >>>>>> #QueryServiceConfig:with:with:with: - PDWORD is >>>>>> undeclared) (WinServiceInterface >>>>>> #EnumServicesStatus:with:with:with:with:with:with:with: - >>>>>> LPENUM_SERVICE_STATUS is undeclared) (WinServiceInterface >>>>>> #SetServiceStatus:with: - LPSERVICE_STATUS is >>>>>> undeclared) (WinServiceInterface >>>>>> #GetServiceDisplayName:with:with:with: >>>>> >>>>> - _arg3 is >>>>> >>>>>> undeclared) (WinServiceInterface >>>>>> >>>>>> >>>>> >>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>> th:with:wi >>>>> >>>>>> th: - _arg4 is undeclared) (WinServiceInterface >>>>>> >>>>>> >>>>> >>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>> th:with:wi >>>>> >>>>>> th: - _arg5 is undeclared) (WinServiceInterface >>>>>> >>>>>> >>>>> >>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>> th:with:wi >>>>> >>>>>> th: - _arg6 is undeclared) (WinServiceInterface >>>>>> >>>>>> >>>>> >>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>> th:with:wi >>>>> >>>>>> th: - _arg7 is undeclared) (WinServiceInterface >>>>>> >>>>>> >>>>> >>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>> th:with:wi >>>>> >>>>>> th: - _arg8 is undeclared) (WinServiceInterface >>>>>> >>>>>> >>>>> >>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>> th:with:wi >>>>> >>>>>> th: - _arg9 is undeclared) (WinServiceInterface >>>>>> >>>>>> >>>>> >>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>> th:with:wi >>>>> >>>>>> th: - _arg10 is undeclared) (WinServiceInterface >>>>>> >>>>>> >>>>> >>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>> th:with:wi >>>>> >>>>>> th: - _arg11 is undeclared) (WinServiceInterface >>>>>> >>>>>> >>>>> >>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>> th:with:wi >>>>> >>>>>> th: - _arg12 is undeclared) (WinServiceInterface >>>>>> #SetServiceObjectSecurity:with:with: - >>>>>> PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface >>>>>> #QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is >>>>>> undeclared) Done >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> -- >> Alan Knight [|], Cincom Smalltalk Development >> [hidden email] >> [hidden email] >> http://www.cincom.com/smalltalk > > > > |
Re: ExternalDictionary corrupted in Store?
|
|
Dear Andres,
> Would you mind verifying the VW build you > saw this problem in before the CTYPE was set? CTYPE has been used in Store since 5i4 at least. I noticed that StoreGlorp was not preserving the value while I was replicating code from other dialects / versions / CM systems to databases connecting to VW7.3.1 and VW7.4 images. AFAIK, there was never a StoreGlorp version that set CTYPEs until I published one in February of last year and recommended it be added to the main StoreGlorp branch, as has just been done. Since StoreBase writes CTYPEs correctly and AFAIK always has, only _replicating_ a package would cause their loss and only if CTYPE-controlled load-sorting was important for that package would it be noticed. (I believe _publishing_ using StoreGlorp instead of StoreBase has been very rare up to now, so replicating should be the only issue.) In principal therefore (IIUC), any package replicated with any main-branch StoreGlorp in the last nigh-on two years (and any version at all before that) will have lost any 'CTYPE' values its stored method versions had. In practice, only a minority even of C-pragma-using utilities will have defined C types and needed them pre-ordered to load correctly. 1) If Alan's email means he has run a StoreGlorp script that wrote CTYPEs for all and only C-type-defining pragma methods in the Cincom OR then there is no longer a problem in that database. (If he meant he had only fixed WinService, there would be need to generalise his script to find all cases.) 2) If (1) then Alan presumably has or will run his script on other Cincom databases that could contain replicated C-type-defining methods. 3) As soon as the script is trusted enough, there is a case for making it available to the community so anyone with a lot of replicated stuff in local databases can check and fix, just in case. HTH. Yours faithfully Niall Ross > Niall, > > Would you mind verifying the VW build you saw this problem in before > the CTYPE was set? > > Thanks, > Andres. > > Niall Ross wrote: > >> Dear Alan, >> my understanding of the code (and my experience - I saw load >> failures of the same kind as the one Steve reports when CTYPE was not >> set) is that it is precisely the C _types_ (only) that are >> front-sorted, so that, by Steve's analysis: >> >> > Yes, that makes sense: the procedures are being compiled before the >> > types, so DWORD etc. aren't available. >> >> having CTYPEs set would fix his problem. >> >> If, that is, the problem arose through StoreGlorp replication >> dropping the CTYPEs; I know no reason why direct publishing via >> StoreBase should lose them (noting that I have not reviewed this code >> since 7.4). Steve, it would be interesting to know >> - whether you can say that the problem you saw did or could, >> or else could not, relate to versions that were replicated? >> and, independently of that, >> - whether the not-loaded-first type pragma'd method has >> CTYPE set or not in the database for the problem version. >> >> Yours faithfully >> Niall Ross >> >>> Hmm, I thought that once upon a time I had looked at that fairly >>> carefully and decided that the CTYPE stuff really wasn't used for >>> anything that made a difference. I think the only thing that it does >>> is move all the CTYPE methods to the beginning. Which means they'll >>> come before other methods, but I would expect that the ordering >>> constraints are between those methods, rather than between them and >>> other methods. But your changes look fine anyway. >>> >>> At 01:42 PM 11/6/2007, Niall Ross wrote: >>> >>>> Dear Steve et al, >>>> basic Store uses CTYPE to handle ExternalInterface ordering >>>> issues (see #sortForLoading:package:) but StoreGlorp did not set >>>> CTYPE when replicating. (Someone, probably reusing a field >>>> previously for something else, set this to be stored in column >>>> 'version' which is a truly dreadful name for it and probably >>>> explains why it went missing.) >>>> >>>> My fix also seems to have gone missing so I republished it last >>>> night to the Cincom OR. It awaits Alan's review. >>>> >>>> If affected packages were published and then replicated, they would >>>> load OK from the DB in which they were published but might not from >>>> the DB to which they were replicated. >>>> >>>> Anyone think this matches what is being seen? >>>> >>>> Yours faithfully >>>> Niall Ross >>>> >>>> > This problem has already surfaced several times during the last >>>> year or >>>> > so. The Registry package and JNIPort both had this issue. You are >>>> not >>>> > alone. ;-) >>>> >>>>> Yes, that makes sense: the procedures are being compiled before the >>>>> types, so DWORD etc. aren't available. Presumably the solution is >>>>> twofold: 1) correct the order on load, and 2) also publish in the >>>>> right >>>>> order (for older VWs to be able to load correctly). Is 2) >>>>> implemented in >>>>> the latest VW dev version? >>>>> >>>>> BTW, why aren't we seeing this more? The order in Store appears >>>>> random, >>>>> so I'd imagine most ExternalInterface packages would have this >>>>> problem >>>>> in at least some procedures. >>>>> Thanks, >>>>> Steve >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Andres Valloud [ mailto:[hidden email]] Sent: 1. >>>>>> marraskuuta 2007 19:53 >>>>>> To: [hidden email] >>>>>> Subject: Re: ExternalDictionary corrupted in Store? >>>>>> >>>>>> >>>>>> Steven, >>>>>> >>>>>> This issue has been recently rectified in VW. It has to do with >>>>>> the fact that, upon loading, the order in which type definitions >>>>>> are compiled has an influence in their final meaning. >>>>>> >>>>>> Thanks, >>>>>> Andres. >>>>>> >>>>>> Steven Kelly wrote: >>>>>> >>>>>> >>>>>>> When I load WinService versions 1.0.9 or earlier from the >>>>>> >>>>>> >>>>>> public Store >>>>>> >>>>>>> into VW 7.4.1, its DLLCC code looks right but most of the >>>>>> >>>>>> >>>>>> procedures >>>>>> >>>>>>> fail. E.g. try running the following line, which should do >>>>>>> nothing (unless you have a Windows service called foobar!): >>>>>>> >>>>>>> WinServiceInterface new deregisterService: 'foobar' >>>>>>> >>>>>>> It gives an "Invalid procedure argument" error, because the >>>>>> >>>>>> >>>>>> function, >>>>>> >>>>>>> defined as >>>>>>> >>>>>>> void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) >>>>>>> >>>>>>> is in the ExternalDictionary as: >>>>>>> >>>>>>> void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, LPCSTR DWORD) >>>>>>> >>>>>>> i.e. the last parameter has kept the LPCSTR type of the previous >>>>>>> argument, and changed DWORD from being the type into being the >>>>>>> parameter name. >>>>>>> >>>>>>> Recompiling the class (e.g. by switching to #debug then >>>>>> >>>>>> >>>>>> back to #full) >>>>>> >>>>>>> gets rid of the problem. But how can I get that change into >>>>>> >>>>>> >>>>>> Store? And >>>>>> >>>>>>> how did it get there in the first place? >>>>>>> >>>>>>> The problem is in all versions of WinService before today, >>>>>> >>>>>> >>>>>> dating back >>>>>> >>>>>>> to 2004. It looks like the variables listed as undeclared in the >>>>>>> Transcript when loading are the problems (log below). As a >>>>>> >>>>>> >>>>>> workaround, >>>>>> >>>>>>> 1.0.10 adds a postLoadBlock to recompileMethods. Any clues >>>>>> >>>>>> >>>>>> as to how >>>>>> >>>>>>> this should be solved properly? >>>>>>> >>>>>>> Cheers, >>>>>>> Steve >>>>>>> >>>>>>> Loading WinService . . . >>>>>>> (WinServiceInterface #StartService:with:with: - _arg1 is >>>>>> >>>>>> >>>>>> undeclared) >>>>>> >>>>>>> (WinServiceInterface #StartService:with:with: - DWORD is >>>>>> >>>>>> >>>>>> undeclared) >>>>>> >>>>>>> (WinServiceInterface #StartService:with:with: - _arg2 is >>>>>> >>>>>> >>>>>> undeclared) >>>>>> >>>>>>> (WinServiceInterface #QueryServiceConfig:with:with:with: - >>>>>>> LPQUERY_SERVICE_CONFIG is undeclared) (WinServiceInterface >>>>>>> #QueryServiceConfig:with:with:with: - PDWORD is >>>>>>> undeclared) (WinServiceInterface >>>>>>> #EnumServicesStatus:with:with:with:with:with:with:with: - >>>>>>> LPENUM_SERVICE_STATUS is undeclared) (WinServiceInterface >>>>>>> #SetServiceStatus:with: - LPSERVICE_STATUS is >>>>>>> undeclared) (WinServiceInterface >>>>>>> #GetServiceDisplayName:with:with:with: >>>>>> >>>>>> >>>>>> - _arg3 is >>>>>> >>>>>> >>>>>>> undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg4 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg5 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg6 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg7 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg8 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg9 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg10 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg11 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg12 is undeclared) (WinServiceInterface >>>>>>> #SetServiceObjectSecurity:with:with: - >>>>>>> PSECURITY_DESCRIPTOR is undeclared) (WinServiceInterface >>>>>>> #QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is >>>>>>> undeclared) Done >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> Alan Knight [|], Cincom Smalltalk Development >>> [hidden email] >>> [hidden email] >>> http://www.cincom.com/smalltalk >> >> >> >> >> > > > |
RE: ExternalDictionary corrupted in Store?
|
|
Niall et al,
DLLCC's automatic recompilation feature has been improved to handle this. Preliminary results indicate that it will be able to cope with missing CTYPE tags. We are verifying the fix. Thanks, Andres. -----Original Message----- From: Niall Ross [mailto:[hidden email]] Sent: Tuesday, November 13, 2007 6:41 AM To: Andres Valloud Cc: [hidden email]; Alan Knight Subject: Re: ExternalDictionary corrupted in Store? Dear Andres, > Would you mind verifying the VW build you > saw this problem in before the CTYPE was set? CTYPE has been used in Store since 5i4 at least. I noticed that StoreGlorp was not preserving the value while I was replicating code from other dialects / versions / CM systems to databases connecting to VW7.3.1 and VW7.4 images. AFAIK, there was never a StoreGlorp version that set CTYPEs until I published one in February of last year and recommended it be added to the main StoreGlorp branch, as has just been done. Since StoreBase writes CTYPEs correctly and AFAIK always has, only _replicating_ a package would cause their loss and only if CTYPE-controlled load-sorting was important for that package would it be noticed. (I believe _publishing_ using StoreGlorp instead of StoreBase has been very rare up to now, so replicating should be the only issue.) In principal therefore (IIUC), any package replicated with any main-branch StoreGlorp in the last nigh-on two years (and any version at all before that) will have lost any 'CTYPE' values its stored method versions had. In practice, only a minority even of C-pragma-using utilities will have defined C types and needed them pre-ordered to load correctly. 1) If Alan's email means he has run a StoreGlorp script that wrote CTYPEs for all and only C-type-defining pragma methods in the Cincom OR then there is no longer a problem in that database. (If he meant he had only fixed WinService, there would be need to generalise his script to find all cases.) 2) If (1) then Alan presumably has or will run his script on other Cincom databases that could contain replicated C-type-defining methods. 3) As soon as the script is trusted enough, there is a case for making it available to the community so anyone with a lot of replicated stuff in local databases can check and fix, just in case. HTH. Yours faithfully Niall Ross > Niall, > > Would you mind verifying the VW build you saw this problem in before > the CTYPE was set? > > Thanks, > Andres. > > Niall Ross wrote: > >> Dear Alan, >> my understanding of the code (and my experience - I saw load >> failures of the same kind as the one Steve reports when CTYPE was not >> set) is that it is precisely the C _types_ (only) that are >> front-sorted, so that, by Steve's analysis: >> >> > Yes, that makes sense: the procedures are being compiled before the >> > types, so DWORD etc. aren't available. >> >> having CTYPEs set would fix his problem. >> >> If, that is, the problem arose through StoreGlorp replication >> dropping the CTYPEs; I know no reason why direct publishing via >> StoreBase should lose them (noting that I have not reviewed this code >> since 7.4). Steve, it would be interesting to know >> - whether you can say that the problem you saw did or could, >> or else could not, relate to versions that were replicated? >> and, independently of that, >> - whether the not-loaded-first type pragma'd method has >> CTYPE set or not in the database for the problem version. >> >> Yours faithfully >> Niall Ross >> >>> Hmm, I thought that once upon a time I had looked at that fairly >>> carefully and decided that the CTYPE stuff really wasn't used for >>> anything that made a difference. I think the only thing that it does >>> is move all the CTYPE methods to the beginning. Which means they'll >>> come before other methods, but I would expect that the ordering >>> constraints are between those methods, rather than between them and >>> other methods. But your changes look fine anyway. >>> >>> At 01:42 PM 11/6/2007, Niall Ross wrote: >>> >>>> Dear Steve et al, >>>> basic Store uses CTYPE to handle ExternalInterface ordering >>>> issues (see #sortForLoading:package:) but StoreGlorp did not set >>>> CTYPE when replicating. (Someone, probably reusing a field >>>> previously for something else, set this to be stored in column >>>> 'version' which is a truly dreadful name for it and probably >>>> explains why it went missing.) >>>> >>>> My fix also seems to have gone missing so I republished it last >>>> night to the Cincom OR. It awaits Alan's review. >>>> >>>> If affected packages were published and then replicated, they would >>>> load OK from the DB in which they were published but might not from >>>> the DB to which they were replicated. >>>> >>>> Anyone think this matches what is being seen? >>>> >>>> Yours faithfully >>>> Niall Ross >>>> >>>> > This problem has already surfaced several times during the last >>>> year or >>>> > so. The Registry package and JNIPort both had this issue. You are >>>> not >>>> > alone. ;-) >>>> >>>>> Yes, that makes sense: the procedures are being compiled before >>>>> the types, so DWORD etc. aren't available. Presumably the solution >>>>> is >>>>> twofold: 1) correct the order on load, and 2) also publish in the >>>>> right order (for older VWs to be able to load correctly). Is 2) >>>>> implemented in the latest VW dev version? >>>>> >>>>> BTW, why aren't we seeing this more? The order in Store appears >>>>> random, so I'd imagine most ExternalInterface packages would have >>>>> this problem in at least some procedures. >>>>> Thanks, >>>>> Steve >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Andres Valloud [ mailto:[hidden email]] Sent: 1. >>>>>> marraskuuta 2007 19:53 >>>>>> To: [hidden email] >>>>>> Subject: Re: ExternalDictionary corrupted in Store? >>>>>> >>>>>> >>>>>> Steven, >>>>>> >>>>>> This issue has been recently rectified in VW. It has to do with >>>>>> the fact that, upon loading, the order in which type definitions >>>>>> are compiled has an influence in their final meaning. >>>>>> >>>>>> Thanks, >>>>>> Andres. >>>>>> >>>>>> Steven Kelly wrote: >>>>>> >>>>>> >>>>>>> When I load WinService versions 1.0.9 or earlier from the >>>>>> >>>>>> >>>>>> public Store >>>>>> >>>>>>> into VW 7.4.1, its DLLCC code looks right but most of the >>>>>> >>>>>> >>>>>> procedures >>>>>> >>>>>>> fail. E.g. try running the following line, which should do >>>>>>> nothing (unless you have a Windows service called foobar!): >>>>>>> >>>>>>> WinServiceInterface new deregisterService: 'foobar' >>>>>>> >>>>>>> It gives an "Invalid procedure argument" error, because the >>>>>> >>>>>> >>>>>> function, >>>>>> >>>>>>> defined as >>>>>>> >>>>>>> void * OpenSCManagerA(LPCSTR, LPCSTR, DWORD) >>>>>>> >>>>>>> is in the ExternalDictionary as: >>>>>>> >>>>>>> void * OpenSCManagerA(LPCSTR _arg1, LPCSTR _arg2, LPCSTR >>>>>>> DWORD) >>>>>>> >>>>>>> i.e. the last parameter has kept the LPCSTR type of the previous >>>>>>> argument, and changed DWORD from being the type into being the >>>>>>> parameter name. >>>>>>> >>>>>>> Recompiling the class (e.g. by switching to #debug then >>>>>> >>>>>> >>>>>> back to #full) >>>>>> >>>>>>> gets rid of the problem. But how can I get that change into >>>>>> >>>>>> >>>>>> Store? And >>>>>> >>>>>>> how did it get there in the first place? >>>>>>> >>>>>>> The problem is in all versions of WinService before today, >>>>>> >>>>>> >>>>>> dating back >>>>>> >>>>>>> to 2004. It looks like the variables listed as undeclared in the >>>>>>> Transcript when loading are the problems (log below). As a >>>>>> >>>>>> >>>>>> workaround, >>>>>> >>>>>>> 1.0.10 adds a postLoadBlock to recompileMethods. Any clues >>>>>> >>>>>> >>>>>> as to how >>>>>> >>>>>>> this should be solved properly? >>>>>>> >>>>>>> Cheers, >>>>>>> Steve >>>>>>> >>>>>>> Loading WinService . . . >>>>>>> (WinServiceInterface #StartService:with:with: - _arg1 is >>>>>> >>>>>> >>>>>> undeclared) >>>>>> >>>>>>> (WinServiceInterface #StartService:with:with: - DWORD is >>>>>> >>>>>> >>>>>> undeclared) >>>>>> >>>>>>> (WinServiceInterface #StartService:with:with: - _arg2 is >>>>>> >>>>>> >>>>>> undeclared) >>>>>> >>>>>>> (WinServiceInterface #QueryServiceConfig:with:with:with: - >>>>>>> LPQUERY_SERVICE_CONFIG is undeclared) (WinServiceInterface >>>>>>> #QueryServiceConfig:with:with:with: - PDWORD is >>>>>>> undeclared) (WinServiceInterface >>>>>>> #EnumServicesStatus:with:with:with:with:with:with:with: - >>>>>>> LPENUM_SERVICE_STATUS is undeclared) (WinServiceInterface >>>>>>> #SetServiceStatus:with: - LPSERVICE_STATUS is >>>>>>> undeclared) (WinServiceInterface >>>>>>> #GetServiceDisplayName:with:with:with: >>>>>> >>>>>> >>>>>> - _arg3 is >>>>>> >>>>>> >>>>>>> undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg4 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg5 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg6 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg7 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg8 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg9 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg10 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg11 is undeclared) (WinServiceInterface >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> #CreateService:with:with:with:with:with:with:with:with:with:wi >>>>>> th:with:wi >>>>>> >>>>>> >>>>>>> th: - _arg12 is undeclared) (WinServiceInterface >>>>>>> #SetServiceObjectSecurity:with:with: - PSECURITY_DESCRIPTOR is >>>>>>> undeclared) (WinServiceInterface >>>>>>> #QueryServiceObjectSecurity:with:with:with:with: - LPDWORD is >>>>>>> undeclared) Done >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> Alan Knight [|], Cincom Smalltalk Development [hidden email] >>> [hidden email] http://www.cincom.com/smalltalk >> >> >> >> >> > > > |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |