VA Smalltalk 9.0 (64-bit)
Locked
 
|
Hi group, we have been eager to evaluate the long awaited 64 bit version of VA Smalltalk. But right at the beginning of setting up a new image, i stumbled across some irregularities. Has anybody succeeded in loading the feature "Mastering ENVY/Developer Tools"? In VA Smalltalk V9.0 (64-bit) the loading processs stops with an error --- Transcript ------------------------------------------------------------- ... Loading z.VA: Mastering ENVY/Developer Tools ... Loading the configuration map Mastering ENVY/Developer Testing Extensions V 8.5.0 [194]... MedPrereqCheckTestCase>>quonk "Reference a (hopefully) nil global" ^ compiler error "undefined" --> MedPrereqCheckerTestFooQuonk Error: 357 Cannot complete the load because MedPrereqCheckTestCase>>#quonk(07.02.2011 08:08:07) does not compile. NOTE: If you reload after executing: EmImageBuilder cancelIfMethodsDoNotCompile: false methods which do not compile will be deleted. Failed trying to load Mastering ENVY/Developer Testing Extensions V 8.5.0 [194]. ---------------------------------------------------------------------------- In VA Smalltalk V9.0 (32-bit) the loading process completes as intended, including the message in the Transcript --- Transcript ------------------------------------------------------------- Loading z.VA: Mastering ENVY/Developer Tools ... Loading the configuration map Mastering ENVY/Developer Testing Extensions V 8.5.0 [194]... Warning: 91 Defined global MedPrereqCheckerTestFooQuonk in unmanaged namespace while loading MedPrereqCheckTestCase>>quonk. Warning: 91 Defined global MedPrereqCheckerTestFOONilGlobal in unmanaged namespace while loading MedPrereqCheckTestCase>>bar. If 2 'Warning: 91' messages are displayed above, they are expected when loading this application. Loading the configuration map Mastering ENVY/Developer Three-Way Differences Browser V 8.0.3 [162]... ... ---------------------------------------------------------------------------- VA Smalltalk V9.0 (32-bit) behaves in the same way as VA Smalltalk V8.5.2, which we're using now. In V9.0 (64-bit) i tried the EmImageBuilder cancelIf... methods. But none of them resulted in the desired behaviour. (We don't really need the above feature, it's just an example. We encounter the same error with our own config maps.) Any ideas? Thanks in advance, Hermann You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Hello Hermann,
-- Yes, this was the basis of my post here if you would like more detail https://groups.google.com/forum/#!topic/va-smalltalk/OLPPCs29nNw The short answer is... The 32-bit bytecodes were cached in ENVY...no need to compile it from source...bytecodes linked directly into compiled method...no compiler error...only Transcript warnings. The 64-bit bytecodes were NOT cached in ENVY....must be compiled from source....source does not compile....compiler error -- Seth On Thursday, October 5, 2017 at 10:14:42 AM UTC-4, Hermann Ottens wrote:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
thank you for your quick reply . Unfortunately, the option EmMethodEdition useLinker: false did not work in the intended way, same error message as before. Hermann You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Hello Hermann,
Not sure what the intended way you refer to is exactly. ‘EmMethodEdition useLinker: false’ does not fix problems, it exposes them. ‘EmMethodEdition useLinker: true’ (the default behavior) does not fix problems, it hides them. Execute ‘EmMethodEdition useLinker: false’ in both your production 32-bit and 9.0 32-bit images and perform your normal loading tests that you think should work. This should now have the same behavior as the 64-bit image. We have opened a case to handle the features on our end that has source that doesn’t compile. On your end, if you have source that doesn’t compile or the load order is doing something like loading code that refers to things (classes, pools...) that don’t load until later...then that will need to be fixed if you want to be able to load clean. In this case, clean meaning all source code is compiled as it is loaded. Hope this helps. — Seth -- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Hello Seth,
-- thank you for your reply and sorry for my being unclear. I try to describe the "intended" way and how to reproduce it. 1. make a working directory with a new abt.icx from <vast>\newimage 2. start VA Smalltalk in the new working directory 3. connect to the library 4. load feature "VA: Mastering ENVY/Developer Tools" To me, the intended behaviour is that the load completes and that the following messages appear in the Transcript: Warning: 91 Defined global MedPrereqCheckerTestFooQuonk in unmanaged namespace while loading MedPrereqCheckTestCase>>quonk. Warning: 91 Defined global MedPrereqCheckerTestFOONilGlobal in unmanaged namespace while loading MedPrereqCheckTestCase>>bar. If 2 'Warning: 91' messages are displayed above, they are expected when loading this application. This is what happens in VAST 8.5.2 and 9.0 (32-Bit). The above mentioned methods of MedPrereqCheckTestCase exist and there are two corresponding entries in Smalltalk unmanagedNamespace. In VAST 9.0 (64-bit) the load either does not complete or, with useLinker-settings or cancelIf...-settings, it completes, but the methods are missing and no globals for the missing objects were defined. Is there any other setting, that i can enable to produces the "Warning: 91" instead of a compiler error? Thanks again. Hermann You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Hello Hermann,
-- Yes, you can arrange things such that it looks like what happens in VAST 8.5.2 and 9.0 (32-bit), but just so everyone is aware...we have chosen to hide the problem if we go down this path. 9.0 (32-bit) only works because it has the same bytecode version as 8.5.2...so it is able to use the cached bytecodes without source compilation. 64-bit bytecodes have a different version level, and there are no cached bytecodes for 64-bit. Therefore the only way it could ever work is to first get it in a state where is compiles. Doing so will allow it to cache the bytecodes in ENVY...from then on the loading will be from the cached bytecodes and it will look like the 32-bit versions. I will demonstrate below. "The above mentioned methods of MedPrereqCheckTestCase Ok, but that's because the source code was never compiled....the bytecodes were linked directly into the compiled method and invalid references in those bytecodes were thrown into the unmangedNamespace bucket. If we don't have any cached bytecodes...that simply can not happen. If you want to go down this path, then the solution is to get the 64-bit bytecodes cached into the ENVY manager. Since the source code is not going to compile, then you must temporarily fix the errors so it can be compiled. Once this happens, the bytecodes will be cached into ENVY. From then on, when you load the code, the 64-bit cached bytecodes will be used. 1. Launch 64-bit image 2. Execute following in the workspace to fix compiler errors. (Temporarily define the missing items in the image) Smalltalk at: #MedPrereqCheckerTestFooQuonk put: nil; at: #MedPrereqCheckerTestFOONilGlobal put: nil 3. Load VA: Mastering ENVY/Developer Tools Result: This should have loaded...and now there are cached 64-bit bytecodes persisted in ENVY 4. Relaunch 64-bit image 5. Load VA: Mastering ENVY/Developer Tools Result: Cached 64-bit bytecodes should be available so this should work. -- Seth On Friday, October 6, 2017 at 8:51:44 AM UTC-4, Hermann Ottens wrote:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Hallo Seth,
-- thank you so much. It worked just as you described. My thinking was obviously caught in the error, that upon encountering an unknown object, the compiler simply declares it in the unmanaged namespace. I guess, now i got it (but i will reread your post "Bytecodes are stored in ENVY/Manager" again just to be sure). In the end this also means that we don't have mere nuisances but errors in our code (what an insight). Thank you again for your quick help. Hermann You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Hello Hermann,
You’re very welcome. I realize the way that it works is obtuse and I’m sure this won’t be the last time it is discussed. If there are additional questions on this, I will be happy to answer. Kind regards, — Seth -- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
Re: VA Smalltalk 9.0 (64-bit)
|
|
In reply to this post by Hermann Ottens
Hi All, Just to say we have tested EsEntryPoint in windows with cdecl calling support and it work fine. Good work with new libffi ! El jueves, 5 de octubre de 2017, 11:14:42 (UTC-3), Hermann Ottens escribió:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
|
|
Greetings Leonardo,
-- Wonderful to hear...thanks for the feedback! Regards, -- Seth On Tuesday, October 24, 2017 at 7:19:58 PM UTC-4, Leonardo Oillataguerre wrote:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
Re: VA Smalltalk 9.0 (64-bit)
|
|
In reply to this post by Leonardo Oillataguerre
After reading this today I sat down and for the first time I was able to use libcurl to make request and send the data directly from libCurl to VASmalltalk under Windows by using callbacks ... now its time to see, how stable it is.
-- I was surprised to see, that from some precompiled libraries (of llibCurl) VASmalltalk/64 was not able to calculate the addresses within the dlls (OS errors 126) - other precompiled libraries of libCurl worked out of the box. That makes so many stuff possible .... Marten Am Mittwoch, 25. Oktober 2017 01:19:58 UTC+2 schrieb Leonardo Oillataguerre:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
«
Return to Instantiations
|
1 view|%1 views
| Free forum by Nabble | Edit this page |