Hi: I remember some old threads about OSProcess. It's ported for Cuis? Where?_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On Fri, Dec 13, 2013 at 09:35:47AM -0200, Germ?n Arduino wrote:
> Hi: > > I remember some old threads about OSProcess. It's ported for Cuis? Where? > Hi Germ?n, I just tried loading OSProcess from some change sets that I exported from Squeak. There are a number of issues to be sorted out, but overall I was able to get it working. I have a question about how to support a package in Cuis. I keep OSProcess in a Monticello repository, and I would like to keep the development sources all in one place. I also would like to support Cuis, and keep Cuis fully up to date with any changes that I might make. What would be a good way to do this? I would not mind going through some extra steps to produce the Cuis version, but I'm not sure the best way to do it. Consider me a newbie here, as I have not yet tried out the Cuis development process, so I may be asking a stupid question here. Thanks, Dave _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Hi Dave
Great that you are willing to support Cuis as well. You are not asking stupid questions but a regular question which we actually have to document in a readme document. So please keep asking questions. A note so far about filing in OSProcess. It is possible to _read_ Monticello files in Cuis. However writing them is not possible in Cuis.The package manager writes a *.pck.st file. Normally what you do it to put the *.pck.st into a github repository. You may put the mcz file which was used to produce it there along side. Regards --Hannes On 12/14/13, David T. Lewis <[hidden email]> wrote: > On Fri, Dec 13, 2013 at 09:35:47AM -0200, Germ?n Arduino wrote: >> Hi: >> >> I remember some old threads about OSProcess. It's ported for Cuis? Where? >> > > Hi Germ?n, > > I just tried loading OSProcess from some change sets that I exported > from Squeak. There are a number of issues to be sorted out, but overall > I was able to get it working. > > I have a question about how to support a package in Cuis. I keep OSProcess > in a Monticello repository, and I would like to keep the development > sources all in one place. I also would like to support Cuis, and keep > Cuis fully up to date with any changes that I might make. What would > be a good way to do this? I would not mind going through some extra > steps to produce the Cuis version, but I'm not sure the best way to > do it. > > Consider me a newbie here, as I have not yet tried out the Cuis development > process, so I may be asking a stupid question here. > > Thanks, > Dave > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
In reply to this post by David T. Lewis
Hi Dave! Great news! In addition of the comments of Hannes, I don't imagine other way to maintain the things because the packages support in Cuis is not based in Monticello.
I can offer my help, for example, to maintain a GitHub version (in the Cuis form of .pck.st) of the package, then each time that you release a new version in the current Monticello format, I should update (checking the differences) the GitHub Cuis version.
I know that is a bit of work (I'm doing some similar job with Aida, Janko send me the diff in a file and then I start a manual work to reshape the things. I'm thinking in ways of automatize this task but as you already know, is a matter of free time).
Currently I need OSProcess because I want to port Banyan Backup of Chris Muller to use as my backup tool. A comment that I want to make also is that to help in the issues that you mention (between Cuis/Squeak/Pharo) I wrote a compatibility layer that may (or may not) help to you in this first port.
In any case, let me know any doubt, I will be glad of help! 2013/12/14 David T. Lewis <[hidden email]>
Saludos / Regards,
Germán Arduino www.arduinosoftware.com _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
In reply to this post by David T. Lewis
On 12/14/2013 3:01 PM, David T. Lewis wrote:
> On Fri, Dec 13, 2013 at 09:35:47AM -0200, Germ?n Arduino wrote: >> Hi: >> >> I remember some old threads about OSProcess. It's ported for Cuis? Where? >> > Hi Germ?n, > > I just tried loading OSProcess from some change sets that I exported > from Squeak. There are a number of issues to be sorted out, but overall > I was able to get it working. > > I have a question about how to support a package in Cuis. I keep OSProcess > in a Monticello repository, and I would like to keep the development > sources all in one place. I also would like to support Cuis, and keep > Cuis fully up to date with any changes that I might make. What would > be a good way to do this? I would not mind going through some extra > steps to produce the Cuis version, but I'm not sure the best way to > do it. > > Consider me a newbie here, as I have not yet tried out the Cuis development > process, so I may be asking a stupid question here. > > Thanks, > Dave Hi David, That would be great! We all would really appreciate if you support Cuis. Yours is a very relevant question. In any case any question you (or anybody) might have is welcome. At worst, it could point to some deficiency in documentation or communication. There are two separate issues. The first is that we don't use Monticello. But we can read MCZ packages, and add a few tools to diff them etc if useful. I don't think the file format will be a serious problem, and I'd like to support the process you come with, and make it the "official suggestion" on how to maintain multi dialect packages. The second issue is library compatibility. There are a few differences between Squeak, Pharo and Cuis, and they affect packages from time to time. If the same person is supporting several dialects (this is not always the case), then a unified code base is best. Sometimes the package can be tweaked to use the common denominator, without a high cost in code clarity or performance. Sometimes, a simple tweak or addition to some dialect might ease things. Count on me wrt that! And sometimes, a compatibility layer is the best option. I'm sure everybody here will be willing to help with that. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On Sat, Dec 14, 2013 at 09:17:21PM -0300, Juan Vuletich wrote:
> On 12/14/2013 3:01 PM, David T. Lewis wrote: > >On Fri, Dec 13, 2013 at 09:35:47AM -0200, Germ?n Arduino wrote: > >>Hi: > >> > >>I remember some old threads about OSProcess. It's ported for Cuis? Where? > >> > >Hi Germ?n, > > > >I just tried loading OSProcess from some change sets that I exported > >from Squeak. There are a number of issues to be sorted out, but overall > >I was able to get it working. > > > >I have a question about how to support a package in Cuis. I keep OSProcess > >in a Monticello repository, and I would like to keep the development > >sources all in one place. I also would like to support Cuis, and keep > >Cuis fully up to date with any changes that I might make. What would > >be a good way to do this? I would not mind going through some extra > >steps to produce the Cuis version, but I'm not sure the best way to > >do it. > > > >Consider me a newbie here, as I have not yet tried out the Cuis development > >process, so I may be asking a stupid question here. > > > >Thanks, > >Dave > > Hi David, > > That would be great! We all would really appreciate if you support Cuis. > > Yours is a very relevant question. In any case any question you (or > anybody) might have is welcome. At worst, it could point to some > deficiency in documentation or communication. > > There are two separate issues. The first is that we don't use > Monticello. But we can read MCZ packages, and add a few tools to diff > them etc if useful. I don't think the file format will be a serious > problem, and I'd like to support the process you come with, and make it > the "official suggestion" on how to maintain multi dialect packages. > > The second issue is library compatibility. There are a few differences > between Squeak, Pharo and Cuis, and they affect packages from time to > time. If the same person is supporting several dialects (this is not > always the case), then a unified code base is best. Sometimes the > package can be tweaked to use the common denominator, without a high > cost in code clarity or performance. Sometimes, a simple tweak or > addition to some dialect might ease things. Count on me wrt that! And > sometimes, a compatibility layer is the best option. I'm sure everybody > here will be willing to help with that. > Hi, I have updated OSProcess with some fixes for Cuis. This is not complete, but it provides a working version that passes most tests when running on an interpreter VM (not Cog). I have been working with fileouts from Squeak and I am not sure how to load an mcz file into Cuis, but if anyone would like to try it, the updated version of OSProcess is here: http://www.squeaksource.com/OSProcess/OSProcess-dtl.87.mcz Before loading this, there are some changes that I made to my Cuis image first. Here is what I did: - Create the class Model as subclass of Object. This can just an empty class, but the classes OSProcessAccessor, AIOEventHandler, and PseudoAioEventHandler are subclassed from Model in Squeak. Or, if you prefer not to have a stub Model class, you can load OSProcess, then fix the class definitions for OSProcessAccessor, AIOEventHandler, and PseudoAioEventHandler to be subclasses of Object (otherwise they end up under ProtoObject, which does not work). - Implement these methods from Squeak: Object>>changed (OSProcess uses changed / update mechanism throughout) Object>>ifNotNilDo: (older versions of Squeak do not handle ifNotNil: the same) Character class>>cr (compatibility, used in many places in OSProcess) Character class>>lf (compatibility, used in many places in OSProcess) StandardFileStream>>fileID (accessor needed by AttachableFileStream) With those methods added, OSProcess can be loaded in Cuis, and most tests will pass. There is no class Socket in Cuis, so tests for socket operations will fail, and there will be some undeclared references to Socket. The line ending conventions are different in Cuis and Squeak (cr versus lf) so the code that I loaded looks ugly in the browser. I am not sure how to fix this (probably I am just loading the files in the wrong way), but the code works so I am not too worried about this right now. It's a start :) Dave _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Hi David: Sorry by the delay but was a busy monday yesterday....2013/12/16 David T. Lewis <[hidden email]>
mmm, I'm having a crash trying to use Cuis 1880 with Squeak 4.1.1 VM and I am not sure how to load an mcz file into Cuis, but if anyone would I usually extract the sources.st from the .mcz, but don't worry I will do it and will prepare a .pck.st. Then you can create a GitHub account and a repo for OSProcess for Cuis. Before loading this, there are some changes that I made to my Cuis image In Cuis we have ActiveModel, to bind models and UIs, an approach designed by Juan and inspired in Visual Smalltalk. May be we should use ActiveModel or you prefer Object? - Implement these methods from Squeak: Character #cr and #lf are already in Cuis, the other modifications I will evaluate if are better to include in the Compatibility Layer or as part of the OSProcess package for Cuis (*osprocess categories). There is no class Socket in Cuis, so tests for socket operations will fail, Yes, Socket is part of the Network Kernel package, not loaded by default in the stock Cuis image. The line ending conventions are different in Cuis and Squeak (cr versus lf) Yes, the way is (previous to load the code, for example in the FileList): 1. Cmd-a Select all 2. Cmd-U Convert line endings to LF characters (Cuis convention) in selection 3. Cmd-s Save and then load the code. It's a start :) Sure, I will do something as soon as have a bit of free time....as produce the .pck.st package to avoid you such task. And also the installation with prereq, to install OSProcess with only a command :) Dave Germán. _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Hi again! Attached you will find a Cuis version of the OSProcess package.To install the code, select it from the FileList and then install, or from a workspace: Feature require: 'OSProcess'. 2013/12/17 Germán Arduino <[hidden email]>
-- Saludos / Regards,
Germán Arduino www.arduinosoftware.com _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org OSProcess.pck.st (712K) Download Attachment |
In reply to this post by garduino
Hey folks Just thinking, having an OSProcess-Cuis compat lib does make some sense if I'm reading David's post clearly. We obviously don't need an empty class in the base system, but it makes perfect sense to load one in order to use OSProcess. In general I think a good goal here will be finding a way for David to avoid having to do extra work to support Cuis. Then we get OSProcess and everyone wins.
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
In reply to this post by garduino
On Tue, Dec 17, 2013 at 09:55:01AM -0200, Germ?n Arduino wrote:
> Hi David: > > Sorry by the delay but was a busy monday yesterday.... > I'm busy too :-) > In Cuis we have ActiveModel, to bind models and UIs, an approach designed > by Juan and inspired in Visual Smalltalk. May be we should use ActiveModel > or you prefer Object? > Probably either one is ok. OSProcess uses the #changed: #update: protocol and in Cuis this is supported for legacy compatibility. If ActiveModel is more efficient when using #changed: #update: then that would probably be better. But Object will definitely work, so if you are not sure, then just use Object. (FYI: At one time, I had updated OSProcess and CommandShell to use the "improved" #when:send:to protocol. At that time, Squeak did not handle weak collections well, and the performance was horrible. So I had to change everything back to use the use the #update protocols. This was a lot of work for me, but the old protocol is fast and efficient and I have not had problems since. So that is why OSProcess uses the old protocol). > > Character #cr and #lf are already in Cuis, the other modifications I will > evaluate if are better to include in the Compatibility Layer or as part of > the OSProcess package for Cuis (*osprocess categories). > OK thanks. > > > There is no class Socket in Cuis, so tests for socket operations will fail, > > and there will be some undeclared references to Socket. > > > > > Yes, Socket is part of the Network Kernel package, not loaded by default in > the stock Cuis image. > Good, that makes sense to me. As you can see I am a newbie :) > > > The line ending conventions are different in Cuis and Squeak (cr versus lf) > > so the code that I loaded looks ugly in the browser. I am not sure how to > > fix this (probably I am just loading the files in the wrong way), but the > > code works so I am not too worried about this right now. > > > > > Yes, the way is (previous to load the code, for example in the FileList): > > 1. Cmd-a Select all > 2. Cmd-U Convert line endings to LF characters (Cuis convention) in > selection > 3. Cmd-s Save > > and then load the code. > Thanks I will try that. I think that there may be some carriage returns embedded in strings in some of the source code, so I will need to check and see if these are a problem. > Sure, I will do something as soon as have a bit of free time....as produce > the .pck.st package to avoid you such task. And also the installation with > prereq, to install OSProcess with only a command :) > Thanks for doing this. I am busy with the holiday season so I may not be able to follow up quickly. Happy holidays to all! Dave _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Hi David
(inline and abridged, without repeating what Germán already said) On 12/17/2013 10:34 PM, David T. Lewis wrote: >> In Cuis we have ActiveModel, to bind models and UIs, an approach designed >> by Juan and inspired in Visual Smalltalk. May be we should use ActiveModel >> or you prefer Object? >> > Probably either one is ok. OSProcess uses the #changed: #update: protocol > and in Cuis this is supported for legacy compatibility. If ActiveModel is more > efficient when using #changed: #update: then that would probably be better. > But Object will definitely work, so if you are not sure, then just use Object. I'm preparing a SqueakCompatibility package, I'll upload it to github tomorrow. It will have Model as an empty subclass of ActiveModel. It will also include #ifNotNilDo: and #fileID. Besides, as Cuis already includes #addDependent:, #changed: and #update:, I'm adding #changed to the base image. > (FYI: At one time, I had updated OSProcess and CommandShell to use the "improved" > #when:send:to protocol. At that time, Squeak did not handle weak collections > well, and the performance was horrible. So I had to change everything back to > use the use the #update protocols. This was a lot of work for me, but the old > protocol is fast and efficient and I have not had problems since. So that is > why OSProcess uses the old protocol). I see. I'd suggest using #wen:send:to: but just because I find it nice, and performance should be good in any recent Squeak image :) . In any case, in Cuis, #addDependent: / #changed: / #update: are implemented using #when:send:to: and #triggerEvent: . So, performance wise, it is the same. > ... > Thanks for doing this. I am busy with the holiday season so I may not be able > to follow up quickly. > > Happy holidays to all! > > Dave Thanks Dave. Happy holidays to all Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
In reply to this post by David T. Lewis
(abridged)
On 12/16/2013 1:08 AM, David T. Lewis wrote: > Hi, > I have updated OSProcess with some fixes for Cuis. This is not complete, > but it provides a working version that passes most tests when running on > an interpreter VM (not Cog). I have been working with fileouts from Squeak > and I am not sure how to load an mcz file into Cuis, but if anyone would > like to try it, the updated version of OSProcess is here: > > http://www.squeaksource.com/OSProcess/OSProcess-dtl.87.mcz > > Before loading this, there are some changes that I made to my Cuis image > first. Here is what I did: > ... > The line ending conventions are different in Cuis and Squeak (cr versus lf) > so the code that I loaded looks ugly in the browser. I am not sure how to > fix this (probably I am just loading the files in the wrong way), but the > code works so I am not too worried about this right now. > > It's a start :) > > Dave Hi Dave, With the appropriate compatibility package and / or some tweaks to Cuis (I described them elsewhere in this thread), it looks like you could support Cuis with exactly the same code as Squeak. Given that extracting the code from a MCZ file is not hard, I could write a simple tool to allow converting an MCZ file to .pck.st format. This tool would also convert newline characters (cr, crlf, lf) to Cuis default: lf. This means that if your code specifically requires a cr or crlf string or character, instead of including them in a string literal, you would need to use #cr, #lf or #crLf. The good part is that your code would be line ending agnostic. BTW, to require a default line terminator, I'd suggest adding #newLineString to Squeak, answering the same as #cr (in Cuis it answers #lf). Would all this be ok for you? If so, all we need to do is to run this tool when you publish a new version of OSProcess.MCZ, and publish the result to the Cuis GitHub repo. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On 18 December 2013 03:45, Juan Vuletich <[hidden email]> wrote:
> (abridged) > On 12/16/2013 1:08 AM, David T. Lewis wrote: >> >> Hi, >> I have updated OSProcess with some fixes for Cuis. This is not complete, >> but it provides a working version that passes most tests when running on >> an interpreter VM (not Cog). I have been working with fileouts from Squeak >> and I am not sure how to load an mcz file into Cuis, but if anyone would >> like to try it, the updated version of OSProcess is here: >> >> http://www.squeaksource.com/OSProcess/OSProcess-dtl.87.mcz >> >> Before loading this, there are some changes that I made to my Cuis image >> first. Here is what I did: >> ... >> >> The line ending conventions are different in Cuis and Squeak (cr versus >> lf) >> so the code that I loaded looks ugly in the browser. I am not sure how to >> fix this (probably I am just loading the files in the wrong way), but the >> code works so I am not too worried about this right now. >> >> It's a start :) >> >> Dave > > > Hi Dave, > > With the appropriate compatibility package and / or some tweaks to Cuis (I > described them elsewhere in this thread), it looks like you could support > Cuis with exactly the same code as Squeak. > > Given that extracting the code from a MCZ file is not hard, I could write a > simple tool to allow converting an MCZ file to .pck.st format. This tool > would also convert newline characters (cr, crlf, lf) to Cuis default: lf. How difficult do you think it would be to write the reverse tool, converting a .pck.st to MCZ? I'm thinking of something that could say "I depend on this repository, at this commit id" and grab something from github. The user just sees an MCZ. I suspect the hard part is the fact that an MCZ has a UUID identifier and a funny name. Something would need to remember that this tag in the git repository mapped to this (UUID, author, version number) triple. A masochist would suggest storing that in the tag itself... frank _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
In reply to this post by Juan Vuletich-4
Hi Juan,
On Wed, Dec 18, 2013 at 12:45:03AM -0300, Juan Vuletich wrote: > > With the appropriate compatibility package and / or some tweaks to Cuis > (I described them elsewhere in this thread), it looks like you could > support Cuis with exactly the same code as Squeak. Yes I agree. > > Given that extracting the code from a MCZ file is not hard, I could > write a simple tool to allow converting an MCZ file to .pck.st format. > This tool would also convert newline characters (cr, crlf, lf) to Cuis > default: lf. I think this tool would be useful, and it would make it easier to bring existing packages into Cuis. > > This means that if your code specifically requires a cr or crlf string > or character, instead of including them in a string literal, you would > need to use #cr, #lf or #crLf. The good part is that your code would be > line ending agnostic. BTW, to require a default line terminator, I'd > suggest adding #newLineString to Squeak, answering the same as #cr (in > Cuis it answers #lf). Yes I agree, and it would be a good thing for me to make those changes. > > Would all this be ok for you? If so, all we need to do is to run this > tool when you publish a new version of OSProcess.MCZ, and publish the > result to the Cuis GitHub repo. Yes this is ok, I like this approach. I should mention also that running OSProcess in Cuis helps to find bugs in OSProcess. For example, OSProcess class>>isUnix was broken, and I did not notice the problem until I loaded it in Cuis. So this is is a good thing. Dave _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
I'm loving this! OSProcess is one of those things such that -- when you need it -- you *really* need it. Also: given that we've gone with Git in Cuisland, any tool that makes getting stuff in and out of MCZ files will greatly reduce the barrier to porting applications over.
I think OSProcess is a great test of the general process, too, because it hasn't got a ton of UI surface that would need to be rewritten to work with Juan's Morphic implementation. On Wed, Dec 18, 2013 at 3:55 PM, David T. Lewis <[hidden email]> wrote: Hi Juan, _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
In reply to this post by Frank Shearar-3
On 12/18/2013 8:42 AM, Frank Shearar wrote:
> On 18 December 2013 03:45, Juan Vuletich<[hidden email]> wrote: >> ... >> Given that extracting the code from a MCZ file is not hard, I could write a >> simple tool to allow converting an MCZ file to .pck.st format. This tool >> would also convert newline characters (cr, crlf, lf) to Cuis default: lf. > How difficult do you think it would be to write the reverse tool, > converting a .pck.st to MCZ? I'm thinking of something that could say > "I depend on this repository, at this commit id" and grab something > from github. The user just sees an MCZ. I suspect the hard part is the > fact that an MCZ has a UUID identifier and a funny name. Something > would need to remember that this tag in the git repository mapped to > this (UUID, author, version number) triple. A masochist would suggest > storing that in the tag itself... I don't know. I've been avoiding learning too much about the internals of Monticello. Given that .pck.st is esentially a changeset, this question is better suited to Monticello experts. BTW, you are thinking about making tools aware of GitHub. I think it better to manage repos with their own tools, and just use the file system from Smalltalk. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On 20 December 2013 14:15, Juan Vuletich <[hidden email]> wrote:
> On 12/18/2013 8:42 AM, Frank Shearar wrote: >> >> On 18 December 2013 03:45, Juan Vuletich<[hidden email]> wrote: >>> >>> ... >>> >>> Given that extracting the code from a MCZ file is not hard, I could write >>> a >>> simple tool to allow converting an MCZ file to .pck.st format. This tool >>> would also convert newline characters (cr, crlf, lf) to Cuis default: lf. >> >> How difficult do you think it would be to write the reverse tool, >> converting a .pck.st to MCZ? I'm thinking of something that could say >> "I depend on this repository, at this commit id" and grab something >> from github. The user just sees an MCZ. I suspect the hard part is the >> fact that an MCZ has a UUID identifier and a funny name. Something >> would need to remember that this tag in the git repository mapped to >> this (UUID, author, version number) triple. A masochist would suggest >> storing that in the tag itself... > > > I don't know. I've been avoiding learning too much about the internals of > Monticello. Given that .pck.st is esentially a changeset, this question is > better suited to Monticello experts. > > BTW, you are thinking about making tools aware of GitHub. I think it better > to manage repos with their own tools, and just use the file system from > Smalltalk. The opposite, actually: if I can map git commits containing changesets to Monticello packages, I can have all the MC tools Just Work(tm). One option is to have a postcommit hook in the git repository that publishes an MCZ based off the changeset, I suppose. (MCZs look a whole lot like jar files, which are closer to deployable artifacts than source code revisions.) frank > Cheers, > Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On 12/20/2013 11:38 AM, Frank Shearar wrote:
> The opposite, actually: if I can map git commits containing changesets > to Monticello packages, I can have all the MC tools Just Work(tm). One > option is to have a postcommit hook in the git repository that > publishes an MCZ based off the changeset, I suppose. (MCZs look a > whole lot like jar files, which are closer to deployable artifacts > than source code revisions.) > > frank I see. Good luck with that. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On 20 December 2013 22:21, Juan Vuletich <[hidden email]> wrote:
> On 12/20/2013 11:38 AM, Frank Shearar wrote: >> >> The opposite, actually: if I can map git commits containing changesets >> to Monticello packages, I can have all the MC tools Just Work(tm). One >> option is to have a postcommit hook in the git repository that >> publishes an MCZ based off the changeset, I suppose. (MCZs look a >> whole lot like jar files, which are closer to deployable artifacts >> than source code revisions.) >> >> frank > > > I see. Good luck with that. That's a very polite way of saying "go away" :) Really, the point I was aiming for was that if OSProcess was hosted in git/on GitHub, and we had such a mapping, it would make Cuis' life easier (hey, it's trivial to wrap up in a pck.st!), and Squeak's and Pharo's no worse (hey, my tools still work!). Because unless we make it easier to cross-pollinate (like sharing a codebase), the work to keep a package running increases at at least O(n), where n is the number of supported dialects. I don't actually expect _you_ to do the work of mapping back to MCZs. You have more than enough on your plate already. But it would be nice to know that if someone did this work, that Cuis wouldn't reject it. frank > Cheers, > Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
In reply to this post by David T. Lewis
Hi Dave,
(below) On 12/18/2013 8:55 PM, David T. Lewis wrote: > Hi Juan, > > On Wed, Dec 18, 2013 at 12:45:03AM -0300, Juan Vuletich wrote: >> With the appropriate compatibility package and / or some tweaks to Cuis >> (I described them elsewhere in this thread), it looks like you could >> support Cuis with exactly the same code as Squeak. > Yes I agree. > >> Given that extracting the code from a MCZ file is not hard, I could >> write a simple tool to allow converting an MCZ file to .pck.st format. >> This tool would also convert newline characters (cr, crlf, lf) to Cuis >> default: lf. > I think this tool would be useful, and it would make it easier to bring > existing packages into Cuis. > >> This means that if your code specifically requires a cr or crlf string >> or character, instead of including them in a string literal, you would >> need to use #cr, #lf or #crLf. The good part is that your code would be >> line ending agnostic. BTW, to require a default line terminator, I'd >> suggest adding #newLineString to Squeak, answering the same as #cr (in >> Cuis it answers #lf). > Yes I agree, and it would be a good thing for me to make those changes. > >> Would all this be ok for you? If so, all we need to do is to run this >> tool when you publish a new version of OSProcess.MCZ, and publish the >> result to the Cuis GitHub repo. > Yes this is ok, I like this approach. > > I should mention also that running OSProcess in Cuis helps to find bugs > in OSProcess. For example, OSProcess class>>isUnix was broken, and I did > not notice the problem until I loaded it in Cuis. So this is is a good > thing. > > Dave > This is nice to know, thanks! I've just pushed to github 18 updates, and 3 updated and 1 new package. Some of the updates and the new package are to support OSProcess code in Cuis. Please check it, and let me know if I forgot about something. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Free forum by Nabble | Edit this page |