Re: [Pharo-users] Iceberg loading a Tonel package migrated using SETT

Dale, Besides the issue affecting this particular case, I think that the Tonel "format" should support and honor "metadata" at the class/package/method level. E.g. the SETT exporter creates the #vw_namespace for classes, other dialects may need to specify other information that would be useful tha

Re: [Pharo-users] Iceberg loading a Tonel package migrated using SETT

SETT was create based on our understanding (GemTalk Systems) of what the tonel disk format was _supposed_ to be and I think that Pharo has departed from somewhat from what was understood to be the format. I've had similar problems trying to use filetree repositories with Iceberg that have been

Re: [Pharo-users] Iceberg loading a Tonel package migrated using SETT

Hi Guillermo, Your workaround effectively solved my issue. About the tonel format, in the .properties file at the sources directory there was such setting: https://github.com/eMaringolo/rbac/blob/9279f22ef5fd1c4149090b5b39a6afa143a6519c/sources/properties.st But the .project file was missing at

Re: [Pharo-users] Iceberg loading a Tonel package migrated using SETT

I’ve created an issue: https://github.com/pharo-vcs/iceberg/issues/1251 > El 18 jun 2019, a las 9:30, Guillermo Polito > escribió: > > Hi Esteban, > > It seems like a bug in Iceberg. If you click on debug, you’ll see that > although you’ve

Re: [Pharo-users] Iceberg loading a Tonel package migrated using SETT

Hi Esteban, It seems like a bug in Iceberg. If you click on debug, you’ll see that although you’ve said the project is in tonel format, it’s trying to use a Filetree reader This is due to some missing metadata in the commit (iceberg is relying on commit information there and not working copy

[Pharo-users] Iceberg loading a Tonel package migrated using SETT

Hi, I'm trying to load a package from a Tonel repository[1] that was created using SETT[2]. The structure seems fine, but when I try to load a package, I'm getting the message saying that there is no version for the package in the current commit (which seems wrong at least to the naked eye). Eg.