Hello, What is the status of Tanker? Cheers, Hernán |
Hello Hernán, It's outdated, we were not taking care of Tanker. I've just updated some urls in the doc, and the Pharo versions in the Jenkins job (it was being run in 2.0 and 3.0!). BTW, have you loaded it from this repo? (we moved from Mariano's repo, but the old one wasn't deleted). Cheers, Martín El jue., 20 ago. 2015 a las 8:24, Hernán Morales Durand (<[hidden email]>) escribió:
|
Hello Martín 2015-08-20 5:31 GMT-03:00 Martin Dias <[hidden email]>:
Yes. I checked the code and PackageInfo usage was intentional (#behaviorsLocalToPackageInfoNamed: , #extensionMethodsToPackageInfoNamed: , etc) , but the tests are generating AnObsoleteClassForTestToBeDeleted... and from there I don't know. Is just that PackageInfo stuff preventing to use Tanker? Could you comment how far is Tanker from being stable or usable? Hernán
TankerPackagesSupport-HernanMoralesDurand.11.mcz (6K) Download Attachment |
That’s something we’ve fixed in Fuel. It’s simply a side effect of the tests, not a functional problem.
I guess Tanker would need to be updated for the changes in CompiledMethod and possibly a couple of changes would be required to account for deprecation etc. I’m not sure how much work it would take to use RPackage / Ring.
I guess we could make it work within a couple of hours / days. So far there was simply no interest from anybody AFAIK. What’s your use case exactly? Cheers, Max
|
Hello Max,
2015-08-20 15:15 GMT-03:00 Max Leske <[hidden email]>:
Good :)
I hope it is not too much work.
Building my PhyloclassTalk app loads > 60 packages and it is taking too much time. I read about loading Seaside in 10 sec. so I want that too :) Another situation is when I show Pharo to solve "easy" tasks (CSV, PetitParser, etc) to people and it doesn't feel nice to wait loading, specially when Python takes 2 secs to install with pip, or they use IPython/anaconda which has everything preloaded. Cheers, Hernán
|
On Thu, Aug 20, 2015 at 3:49 PM, Hernán Morales Durand <[hidden email]> wrote:
One of the problems that never got fixed in Tanker was that if the superclass of a class you are loading has changed instVars from where you have exported, then the compiled methods will be wrong and bytecodes will access a shifted instvar (this is one of the scenarios, but there are a couple). Of course, nice solutions could be developed to even avoid compilation (I remember Marcus telling us to get IR -- intermediate representation -- from compiled method, then change instVas, and get new compiled method. But... even without that, we still never developed the most basic solution which would detect such a case and do a normal compilation from source (source is ALSO serialized anyway). Until we develop that, I think it won't be stable.
|
In reply to this post by hernanmd
Well yes but that’s only possible if you first export the code in the Tanker format. And you don’t want to do that for every new version (unless of course, Tanker were the default format…).
I know what you mean. We have builds on our build server that take up to 30 minutes. I once thought to have multiple stages of builds to reduce build times but that wont work in this case of course.
|
Hernán,
thanks for the contribution, I copied it to the repository. I think you can commit without any special permission. I took a look in the errors and I found that it uses SourceFilesArray API that we removed in Pharo 5.0... indeed, in Tanker we made strong assumptions about the changes files. I did a pass migrating code to current Pharo (50249). Mariano: yes, we didn't implement recompilation when something changed in the format. Max: I agree Tanker has to use RPackage instead of PackageInfo, but I'm not sure it needs to be moved to Ring. Martín El jue., 20 ago. 2015 a las 21:22, Max Leske (<[hidden email]>) escribió:
|
In reply to this post by Mariano Martinez Peck
Hi Mariano,
2015-08-20 15:54 GMT-03:00 Mariano Martinez Peck <[hidden email]>:
Thank you for the detailed explanation. Hernán
|
Free forum by Nabble | Edit this page |