Package comments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Package comments

Sergio Fedi
Can Packages have comments or something explaining its purpose or use?

Reply | Threaded
Open this post in threaded view
|

Re: Package comments

EstebanLM
not yet.
we have real packages support since not much time.
now we also have the concept of “Package Manifest” where you can put comments and other stuff.

… but the tools are not yet ready :(

Esteban

> On 30 Apr 2015, at 14:52, Sergio Fedi <[hidden email]> wrote:
>
> Can Packages have comments or something explaining its purpose or use?
>


Reply | Threaded
Open this post in threaded view
|

Re: Package comments

Sergio Fedi
Thanks :) 

I'm gonna investigate the Package Manifest

On Thu, Apr 30, 2015 at 9:55 AM, Esteban Lorenzano <[hidden email]> wrote:
not yet.
we have real packages support since not much time.
now we also have the concept of “Package Manifest” where you can put comments and other stuff.

… but the tools are not yet ready :(

Esteban

> On 30 Apr 2015, at 14:52, Sergio Fedi <[hidden email]> wrote:
>
> Can Packages have comments or something explaining its purpose or use?
>



Reply | Threaded
Open this post in threaded view
|

Re: Package comments

Sean P. DeNigris
Administrator
In reply to this post by EstebanLM
EstebanLM wrote
now we also have the concept of “Package Manifest” where you can put comments and other stuff.
Why does RPackage>>#packageManifest (which should just be named #manifest) return an instance of the manifest class, but all metadata is on the class side?
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Package comments

EstebanLM

> On 01 May 2015, at 03:27, Sean P. DeNigris <[hidden email]> wrote:
>
> EstebanLM wrote
>> now we also have the concept of “Package Manifest” where you can put
>> comments and other stuff.
>
> Why does RPackage>>#packageManifest (which should just be named #manifest)
> return an instance of the manifest class, but all metadata is on the class
> side?

probably a bug :)

Esteban

>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Package-comments-tp4823188p4823415.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Package comments

Uko2
One question, is someone working this kind of metadata management? Because
1) instead of keeping it in the class, we can keep it in objects.
2) It can be serialized into STON for git versioning and probably it can be stored in some way in Monticello

Uko

> On 01 May 2015, at 12:07, Esteban Lorenzano <[hidden email]> wrote:
>
>
>> On 01 May 2015, at 03:27, Sean P. DeNigris <[hidden email]> wrote:
>>
>> EstebanLM wrote
>>> now we also have the concept of “Package Manifest” where you can put
>>> comments and other stuff.
>>
>> Why does RPackage>>#packageManifest (which should just be named #manifest)
>> return an instance of the manifest class, but all metadata is on the class
>> side?
>
> probably a bug :)
>
> Esteban
>
>>
>>
>>
>> -----
>> Cheers,
>> Sean
>> --
>> View this message in context: http://forum.world.st/Package-comments-tp4823188p4823415.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Package comments

Marcus Denker-4

> On 01 May 2015, at 12:45, Yuriy Tymchuk <[hidden email]> wrote:
>
> One question, is someone working this kind of metadata management? Because
> 1) instead of keeping it in the class, we can keep it in objects.
> 2) It can be serialized into STON for git versioning and probably it can be stored in some way in Monticello
>

I don’t like in general to have data in methods…

For Monticello, we really should add file storage.

it’s easy

-> add ivar to RPackage
-> annualise it lazily with an in-Memory filesystem
-> on MC save, copy the files into a “resources” subdirectory of the zip file.
-> on load, just load the files from the “resources” subdirectory into the in-memory
filesystem.
-> add a tool to add files to the in memory filesystem. The best here would be
to add support to GTInspector to copy files —> DONE.

        Marcus