[Pharo-dev] Sharing/Versioning Data
How do we do this now with MC? Are there options other than "encode in string returned by method" like I've seen done for image data? My use case is that I have a very static domain, and so doesn't require user changes. I think the easiest way to distribute it would be to edit the data on a dev image, and then somehow save the data in a way that can be committed with MC so that loading via MetaC config loads the latest version of the data. What would be the best way to do that? Thanks. p.s. on a related note, I'm also interested in distributing static files with the code e.g. maybe a PDF readme - Cheers, Sean -- View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Sharing/Versioning Data
With Martin we started on friday to sketch a kind of resource manager with an internal file system. Our idea is to plug a resource manager to each package and then serialize a fuel file of it inside the mc package. But we just started it... On Sun, Jun 29, 2014 at 5:22 AM, Sean P. DeNigris wrote: > How do we do this now with MC? Are there options other than "encode in > string > returned by method" like I've seen done for image data? > > My use case is that I have a very static domain, and so doesn't require > user > changes. I think the easiest way to distribute it would be to edit the data > on a dev image, and then somehow save the data in a way that can be > committed with MC so that loading via MetaC config loads the latest version > of the data. What would be the best way to do that? > > Thanks. > > p.s. on a related note, I'm also interested in distributing static files > with the code e.g. maybe a PDF readme > > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Sharing-Versioning-Data-tp4765528.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >
Re: [Pharo-dev] Sharing/Versioning Data
Have a look at ConfigurationOfNacl in doits category, I've used Dropbox to download resource files to a directory. Hernán 2014-06-29 0:22 GMT-03:00 Sean P. DeNigris : > How do we do this now with MC? Are there options other than "encode in > string > returned by method" like I've seen done for image data? > > My use case is that I have a very static domain, and so doesn't require > user > changes. I think the easiest way to distribute it would be to edit the data > on a dev image, and then somehow save the data in a way that can be > committed with MC so that loading via MetaC config loads the latest version > of the data. What would be the best way to do that? > > Thanks. > > p.s. on a related note, I'm also interested in distributing static files > with the code e.g. maybe a PDF readme > > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Sharing-Versioning-Data-tp4765528.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >
Re: [Pharo-dev] Sharing/Versioning Data
Guillermo Polito wrote > With Martin we started on friday to sketch a kind of resource manager Sounds exciting. Can't wait to play with it! - Cheers, Sean -- View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528p4765645.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Sharing/Versioning Data
Hernán Morales Durand wrote > I've used Dropbox to > download resource files to a directory. Thanks I'll check it out - Cheers, Sean -- View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528p4765646.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Sharing/Versioning Data
Hi Sean! I guess you can use the very same technique to store pictures in the image. Mime64 is your friend :-) I can look for code snippets if you need… Let me know Cheers, Alexandre On Jun 28, 2014, at 11:22 PM, Sean P. DeNigris wrote: > How do we do this now with MC? Are there options other than "encode in string > returned by method" like I've seen done for image data? > > My use case is that I have a very static domain, and so doesn't require user > changes. I think the easiest way to distribute it would be to edit the data > on a dev image, and then somehow save the data in a way that can be > committed with MC so that loading via MetaC config loads the latest version > of the data. What would be the best way to do that? > > Thanks. > > p.s. on a related note, I'm also interested in distributing static files > with the code e.g. maybe a PDF readme > > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Sharing-Versioning-Data-tp4765528.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Sharing/Versioning Data
Hi Guillermo, On Sat, Jun 28, 2014 at 11:07 PM, Guillermo Polito < guillermopol...@gmail.com> wrote: > With Martin we started on friday to sketch a kind of resource manager with > an internal file system. Our idea is to plug a resource manager to each > package and then serialize a fuel file of it inside the mc package. > I like the idea of a file system, but don't like the idea of an internal file system. The issue here is that I will probably want to use external tools to create the external data, and will want to export the external data from Monticello to an external file system when I come to deploy (that's the point right?). So the issue is how to provide a nice interface to determining which external files are part of a package and in including them in the externalization of a Monticello package (e.g. the zip format of an mcz would seem to be adequate). 2¢ > But we just started it... > Good luck! The one glaring hole in all the Smalltalk versioning systems I've seen so far is the lack of support for external data. I hope you succeed!! > On Sun, Jun 29, 2014 at 5:22 AM, Sean P. DeNigris > wrote: > >> How do we do this now with MC? Are there options other than "encode in >> string >> returned by method" like I've seen done for image data? >> >> My use case is that I have a very static domain, and so doesn't require >> user >> changes. I think the easiest way to distribute it would be to edit the >> data >> on a dev image, and then somehow save the data in a way that can be >> committed with MC so that loading via MetaC config loads the latest >> version >> of the data. What would be the best way to do that? >> >> Thanks. >> >> p.s. on a related note, I'm also interested in distributing static files >> with the code e.g. maybe a PDF readme >> >> >> >> - >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Sharing-Versioning-Data-tp4765528.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > -- best, Eliot
Re: [Pharo-dev] Sharing/Versioning Data
Ah, interesting. I was looking at the theme icons yesterday and importing/exporting those would benefit from this view on resources. Also, there is the Seaside WAFileLibrary which provides some support on that front, allowing one to do a #deployFiles and get them out and also there is the support for getting them in. There is no Fuel file there. For Fuel, the main pain point is when there is an upgrade of Fuel (somewhat unexpected to the user) that renders the existing files unreadable. I had that on a StartUp and it made things weird... Not sure we want to use Fuel then. Phil On Wed, Jul 2, 2014 at 2:44 AM, Eliot Miranda wrote: > Hi Guillermo, > > > On Sat, Jun 28, 2014 at 11:07 PM, Guillermo Polito < > guillermopol...@gmail.com> wrote: > >> With Martin we started on friday to sketch a kind of resource manager >> with an internal file system. Our idea is to plug a resource manager to >> each package and then serialize a fuel file of it inside the mc package. >> > > I like the idea of a file system, but don't like the idea of an internal > file system. The issue here is that I will probably want to use external > tools to create the external data, and will want to export the external > data from Monticello to an external file system when I come to deploy > (that's the point right?). So the issue is how to provide a nice interface > to determining which external files are part of a package and in including > them in the externalization of a Monticello package (e.g. the zip format of > an mcz would seem to be adequate). > > 2¢ > > >> But we just started it... >> > > Good luck! The one glaring hole in all the Smalltalk versioning systems > I've seen so far is the lack of support for external data. I hope you > succeed!! > > >> On Sun, Jun 29, 2014 at 5:22 AM, Sean P. DeNigris >> wrote: >> >>> How do we do this now with MC? Are there options other than "encode in >>> string >>> returned by method" like I've seen done for image data? >>> >>> My use case is that I have a very static domain, and so doesn't require >>> user >>> changes. I think the easiest way to distribute it would be to edit the >>> data >>> on a dev image, and then somehow save the data in a way that can be >>> committed with MC so that loading via MetaC config loads the latest >>> version >>> of the data. What would be the best way to do that? >>> >>> Thanks. >>> >>> p.s. on a related note, I'm also interested in distributing static files >>> with the code e.g. maybe a PDF readme >>> >>> >>> >>> - >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/Sharing-Versioning-Data-tp4765528.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> > > > -- > best, > Eliot >
Re: [Pharo-dev] Sharing/Versioning Data
abergel wrote
> Mime64 is your friend :-)
Thanks for the pointer! I did a little experiment... how does this look?
sampleObjectToSerialize := { Date today. Time now }.
ba := ByteArray streamContents: [ :str | FLSerializer serialize:
sampleObjectToSerialize on: str ].
storableInMethod := ba base64Encoded.
FLMaterializer materializeFromByteArray: storableInMethod base64Decoded
asByteArray.
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Sharing-Versioning-Data-tp4765528p4766933.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
