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.
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 <sean@clipperadams.com> 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.
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.
Hi Guillermo, On Sat, Jun 28, 2014 at 11:07 PM, Guillermo Polito < guillermopolito@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 <sean@clipperadams.com> 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
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 <eliot.miranda@gmail.com> wrote:
Hi Guillermo,
On Sat, Jun 28, 2014 at 11:07 PM, Guillermo Polito < guillermopolito@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 <sean@clipperadams.com> 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
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 <sean@clipperadams.com>:
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.
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.
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 <sean@clipperadams.com> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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.
participants (6)
-
Alexandre Bergel -
Eliot Miranda -
Guillermo Polito -
Hernán Morales Durand -
phil＠highoctane.be -
Sean P. DeNigris