Recreating a binary stack from xml text

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Recreating a binary stack from xml text

Alejandro Tejada
Recently, Michael Chean asked about the possibility
of using svn for version control of livecode stacks.
http://betterexplained.com/articles/a-visual-guide-to-version-control/

But, checking the mail list, I found that many developers
have created code to save stacks as xml.

Now, my question is: It is possible to recreate a binary stack
from xml text, assigning always the same IDs to the same
controls and include in these controls any script with more
than 10 lines?

Thanks in advance!

Al
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Malte Brill
Hi Al,

as of LiveCode version 5 (maybe 4.6.4) this is possible (with the limitation of embedded audioClips and embedded videoClips, as I do not see a way to get the binary data from them). The engine was changed to allow the setting of IDs for any control for exactly that reason. Basically now it is sitting down and loop through a stack to extract all necesssary data and then write the reverse script. As long as you use the liveCode IDE the scriptlimits is not a problem either. The 10 lines limit only affects standalone applications. At the moment my time is too limited to implement this full blown, but I am glad to lend a hand if time permits. I want this too, so this might be interesting (unless there is a 3rd party solution already in the making and getting out of early alpha state soon, that I am not aware of).


All the best,

Malte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Peter Haworth-2
I saw a post earlier in this thread that perhaps Mark Wieder might be
working on something along these lines.  Mark, can you comment?
Pete

On Sat, Feb 18, 2012 at 10:47 AM, Malte Brill <[hidden email]>wrote:

> Hi Al,
>
> as of LiveCode version 5 (maybe 4.6.4) this is possible (with the
> limitation of embedded audioClips and embedded videoClips, as I do not see
> a way to get the binary data from them). The engine was changed to allow
> the setting of IDs for any control for exactly that reason. Basically now
> it is sitting down and loop through a stack to extract all necesssary data
> and then write the reverse script. As long as you use the liveCode IDE the
> scriptlimits is not a problem either. The 10 lines limit only affects
> standalone applications. At the moment my time is too limited to implement
> this full blown, but I am glad to lend a hand if time permits. I want this
> too, so this might be interesting (unless there is a 3rd party solution
> already in the making and getting out of early alpha state soon, that I am
> not aware of).
>
>
> All the best,
>
> Malte
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


--
Pete
Molly's Revenge <http://www.mollysrevenge.com>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

mwieder
Pete-

Saturday, February 18, 2012, 11:33:51 AM, you wrote:

> I saw a post earlier in this thread that perhaps Mark Wieder might be
> working on something along these lines.  Mark, can you comment?

If revOnline ever comes back (hello rev team?) I'll post a stack that
does the translations.

Getting to an from xml format isn't that much of a problem technically
now that ids are no longer immutable. What's a bit more of a brain
teaser is preserving the object hierarchy at the same time. I opted
for individual xml files for each control, card, and stack, as well as
a project xml file that describes how the objects are organized. That
way you can create the entire stack from the xml descriptions or just
pick out individual controls and recreate them.

Creating an object from the xml description is a matter of looping
through the properties, as in

-- in a try construct to handle read-only properties
try
  set the <property> of <object> to <attribute>
catch e
end try

<stack>
 <card>
  <group>
   <control>
    <property>
    </property>
   </control>
  </group>
  <control>
  </control>
 </card>
 <substack>
 ... etc
 </substack>
</stack>

--
-Mark Wieder
 [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Geoff Canyon Rev
http://www.inspiredlogic.com/mc/ripper.html

I created mcRipper oh so many years ago. MC = MetaCard gives you some idea how long ago. As I recall it handled just about everything, but I haven't touched it in over ten years. Anyone is free to take a look and laugh at my code.

Sent from my iPad

On Feb 18, 2012, at 2:07 PM, Mark Wieder <[hidden email]> wrote:

> Pete-
>
> Saturday, February 18, 2012, 11:33:51 AM, you wrote:
>
>> I saw a post earlier in this thread that perhaps Mark Wieder might be
>> working on something along these lines.  Mark, can you comment?
>
> If revOnline ever comes back (hello rev team?) I'll post a stack that
> does the translations.
>
> Getting to an from xml format isn't that much of a problem technically
> now that ids are no longer immutable. What's a bit more of a brain
> teaser is preserving the object hierarchy at the same time. I opted
> for individual xml files for each control, card, and stack, as well as
> a project xml file that describes how the objects are organized. That
> way you can create the entire stack from the xml descriptions or just
> pick out individual controls and recreate them.
>
> Creating an object from the xml description is a matter of looping
> through the properties, as in
>
> -- in a try construct to handle read-only properties
> try
>  set the <property> of <object> to <attribute>
> catch e
> end try
>
> <stack>
> <card>
>  <group>
>   <control>
>    <property>
>    </property>
>   </control>
>  </group>
>  <control>
>  </control>
> </card>
> <substack>
> ... etc
> </substack>
> </stack>
>
> --
> -Mark Wieder
> [hidden email]
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

J. Landman Gay
In reply to this post by mwieder
On 2/18/12 2:07 PM, Mark Wieder wrote:

> If revOnline ever comes back (hello rev team?)

I haven't been able to view, log in, or anything else on revOnline for a
while now. Last night I figured it out. It works normally with LiveCode
4.x, it breaks completely with LiveCode 5.x.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Peter Haworth-2
In reply to this post by mwieder
Hi Mark,
Thanks for the update.  Like several other people, I'm really frustrated by
the non-opertaion of revOnline.  I understand that the team has a lot on
their hands right now but the thing has been broken for months as far as I
can tell.  Maybe we should open a community Dropbox or Box.net account that
allows us all to share useful stacks.

Back to the topic.

I've been thinking about doing something along these lines but haven't had
a chance to actually do anything other than think about the concept.  Most
of the posts I've seen about this topic seem to base the solution on XML
but I'm thinking of using an sqlite database.  What can I say, I'm a
database guy, I understand them, I don't know much about XML.  Using a DB
would make it very easy to address the issue you raised regarding
recreating only part of a stack rather than the whole stack.

If I had the time, I'd like to do this in the context of a version control
system that would store the info about different versions of a stack and
allow comparison between versions to see what changed, not just in scripts
but in any of the stack constructs.  I think that would be a useful and
fairly straightforward thing to do in the context of a database.  In fact,
while we're at it, why not add bug tracking capabilties.

Wish I had time to do it.

Pete

On Sat, Feb 18, 2012 at 12:07 PM, Mark Wieder <[hidden email]>wrote:

> Pete-
>
> Saturday, February 18, 2012, 11:33:51 AM, you wrote:
>
> > I saw a post earlier in this thread that perhaps Mark Wieder might be
> > working on something along these lines.  Mark, can you comment?
>
> If revOnline ever comes back (hello rev team?) I'll post a stack that
> does the translations.
>
> Getting to an from xml format isn't that much of a problem technically
> now that ids are no longer immutable. What's a bit more of a brain
> teaser is preserving the object hierarchy at the same time. I opted
> for individual xml files for each control, card, and stack, as well as
> a project xml file that describes how the objects are organized. That
> way you can create the entire stack from the xml descriptions or just
> pick out individual controls and recreate them.
>
> Creating an object from the xml description is a matter of looping
> through the properties, as in
>
> -- in a try construct to handle read-only properties
> try
>  set the <property> of <object> to <attribute>
> catch e
> end try
>
> <stack>
>  <card>
>  <group>
>   <control>
>    <property>
>    </property>
>   </control>
>  </group>
>  <control>
>  </control>
>  </card>
>  <substack>
>  ... etc
>  </substack>
> </stack>
>
> --
> -Mark Wieder
>  [hidden email]
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


--
Pete
Molly's Revenge <http://www.mollysrevenge.com>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Michael Doub
I think the real intent is to get a livecode application into a format where you can use standard configuration management tools to store versions and track differences.  In theory if the components were broken out separately, then you could have multiple people working on the same app at the same time.  

I believe as long as the source is text, then all of source management systems that I am aware of will work.  XML is just text so it should be fine.  Most of these system can deal with binary blobs and they just rev stamp them. So images and media are still manageable.  

Not having the ability to manage the source code was the only thing that prevented me from using livecode in my corporate life.  So I am excited to hear that others are interested as well.

  -= Mike
 

Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: Pete <[hidden email]>
Sender: [hidden email]
Date: Sat, 18 Feb 2012 13:12:26
To: How to use LiveCode<[hidden email]>
Reply-To: How to use LiveCode <[hidden email]>
Subject: Re: Recreating a binary stack from xml text

Hi Mark,
Thanks for the update.  Like several other people, I'm really frustrated by
the non-opertaion of revOnline.  I understand that the team has a lot on
their hands right now but the thing has been broken for months as far as I
can tell.  Maybe we should open a community Dropbox or Box.net account that
allows us all to share useful stacks.

Back to the topic.

I've been thinking about doing something along these lines but haven't had
a chance to actually do anything other than think about the concept.  Most
of the posts I've seen about this topic seem to base the solution on XML
but I'm thinking of using an sqlite database.  What can I say, I'm a
database guy, I understand them, I don't know much about XML.  Using a DB
would make it very easy to address the issue you raised regarding
recreating only part of a stack rather than the whole stack.

If I had the time, I'd like to do this in the context of a version control
system that would store the info about different versions of a stack and
allow comparison between versions to see what changed, not just in scripts
but in any of the stack constructs.  I think that would be a useful and
fairly straightforward thing to do in the context of a database.  In fact,
while we're at it, why not add bug tracking capabilties.

Wish I had time to do it.

Pete

On Sat, Feb 18, 2012 at 12:07 PM, Mark Wieder <[hidden email]>wrote:

> Pete-
>
> Saturday, February 18, 2012, 11:33:51 AM, you wrote:
>
> > I saw a post earlier in this thread that perhaps Mark Wieder might be
> > working on something along these lines.  Mark, can you comment?
>
> If revOnline ever comes back (hello rev team?) I'll post a stack that
> does the translations.
>
> Getting to an from xml format isn't that much of a problem technically
> now that ids are no longer immutable. What's a bit more of a brain
> teaser is preserving the object hierarchy at the same time. I opted
> for individual xml files for each control, card, and stack, as well as
> a project xml file that describes how the objects are organized. That
> way you can create the entire stack from the xml descriptions or just
> pick out individual controls and recreate them.
>
> Creating an object from the xml description is a matter of looping
> through the properties, as in
>
> -- in a try construct to handle read-only properties
> try
>  set the <property> of <object> to <attribute>
> catch e
> end try
>
> <stack>
>  <card>
>  <group>
>   <control>
>    <property>
>    </property>
>   </control>
>  </group>
>  <control>
>  </control>
>  </card>
>  <substack>
>  ... etc
>  </substack>
> </stack>
>
> --
> -Mark Wieder
>  [hidden email]
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


--
Pete
Molly's Revenge <http://www.mollysrevenge.com>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Peter Haworth-2
Good point Mike.  I think the db approach might provide some added benefits
but as you say, standard cvs systems require text to work from.  Could get
the best of both worlds by providing the ability to create XML from the
database if there are, in fact, any benefits from using a db.
Pete

On Sat, Feb 18, 2012 at 2:43 PM, <[hidden email]> wrote:

> I think the real intent is to get a livecode application into a format
> where you can use standard configuration management tools to store versions
> and track differences.  In theory if the components were broken out
> separately, then you could have multiple people working on the same app at
> the same time.
>
> I believe as long as the source is text, then all of source management
> systems that I am aware of will work.  XML is just text so it should be
> fine.  Most of these system can deal with binary blobs and they just rev
> stamp them. So images and media are still manageable.
>
> Not having the ability to manage the source code was the only thing that
> prevented me from using livecode in my corporate life.  So I am excited to
> hear that others are interested as well.
>
>  -= Mike
>
>
> Sent from my BlackBerry device on the Rogers Wireless Network
>
> -----Original Message-----
> From: Pete <[hidden email]>
> Sender: [hidden email]
> Date: Sat, 18 Feb 2012 13:12:26
> To: How to use LiveCode<[hidden email]>
> Reply-To: How to use LiveCode <[hidden email]>
> Subject: Re: Recreating a binary stack from xml text
>
> Hi Mark,
> Thanks for the update.  Like several other people, I'm really frustrated by
> the non-opertaion of revOnline.  I understand that the team has a lot on
> their hands right now but the thing has been broken for months as far as I
> can tell.  Maybe we should open a community Dropbox or Box.net account that
> allows us all to share useful stacks.
>
> Back to the topic.
>
> I've been thinking about doing something along these lines but haven't had
> a chance to actually do anything other than think about the concept.  Most
> of the posts I've seen about this topic seem to base the solution on XML
> but I'm thinking of using an sqlite database.  What can I say, I'm a
> database guy, I understand them, I don't know much about XML.  Using a DB
> would make it very easy to address the issue you raised regarding
> recreating only part of a stack rather than the whole stack.
>
> If I had the time, I'd like to do this in the context of a version control
> system that would store the info about different versions of a stack and
> allow comparison between versions to see what changed, not just in scripts
> but in any of the stack constructs.  I think that would be a useful and
> fairly straightforward thing to do in the context of a database.  In fact,
> while we're at it, why not add bug tracking capabilties.
>
> Wish I had time to do it.
>
> Pete
>
> On Sat, Feb 18, 2012 at 12:07 PM, Mark Wieder <[hidden email]
> >wrote:
>
> > Pete-
> >
> > Saturday, February 18, 2012, 11:33:51 AM, you wrote:
> >
> > > I saw a post earlier in this thread that perhaps Mark Wieder might be
> > > working on something along these lines.  Mark, can you comment?
> >
> > If revOnline ever comes back (hello rev team?) I'll post a stack that
> > does the translations.
> >
> > Getting to an from xml format isn't that much of a problem technically
> > now that ids are no longer immutable. What's a bit more of a brain
> > teaser is preserving the object hierarchy at the same time. I opted
> > for individual xml files for each control, card, and stack, as well as
> > a project xml file that describes how the objects are organized. That
> > way you can create the entire stack from the xml descriptions or just
> > pick out individual controls and recreate them.
> >
> > Creating an object from the xml description is a matter of looping
> > through the properties, as in
> >
> > -- in a try construct to handle read-only properties
> > try
> >  set the <property> of <object> to <attribute>
> > catch e
> > end try
> >
> > <stack>
> >  <card>
> >  <group>
> >   <control>
> >    <property>
> >    </property>
> >   </control>
> >  </group>
> >  <control>
> >  </control>
> >  </card>
> >  <substack>
> >  ... etc
> >  </substack>
> > </stack>
> >
> > --
> > -Mark Wieder
> >  [hidden email]
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
>
>
> --
> Pete
> Molly's Revenge <http://www.mollysrevenge.com>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


--
Pete
Molly's Revenge <http://www.mollysrevenge.com>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Michael Chean
In reply to this post by Michael Doub
Thanks for this interesting thread.  In thinking about my question, I
realized that the lack of a LC to script
export, thus limiting the ability to use the many fine source controls out
there is a real no-go for multi
developer teams.  Fortunately there is just one of me, so it's not an drop
dead issue. But anyone who uses
one of these tools, I'm willing to bet, will never go back, and of course
the ability to use tools like GIT and
would increase the visibility of LiveCode. Also, if I'm successful, I will
no longer be a one man shop, and at that
point it will become a growing necessity.
 In reading the case-studies I noticed that the one from the University of
Vienna sounds like they rolled their own, ugh!  I've used propietary source
code repositories, and I think that there is no good argument for them in
the small developer shops considering the many existing systems out there.
I would be very interested in this ability, though I hope that it is  part
of  LiveCode at some point.




On Sat, Feb 18, 2012 at 2:43 PM, <[hidden email]> wrote:

> I think the real intent is to get a livecode application into a format
> where you can use standard configuration management tools to store versions
> and track differences.  In theory if the components were broken out
> separately, then you could have multiple people working on the same app at
> the same time.
>
> I believe as long as the source is text, then all of source management
> systems that I am aware of will work.  XML is just text so it should be
> fine.  Most of these system can deal with binary blobs and they just rev
> stamp them. So images and media are still manageable.
>
> Not having the ability to manage the source code was the only thing that
> prevented me from using livecode in my corporate life.  So I am excited to
> hear that others are interested as well.
>
>  -= Mike
>
>
> Sent from my BlackBerry device on the Rogers Wireless Network
>
> -----Original Message-----
> From: Pete <[hidden email]>
> Sender: [hidden email]
> Date: Sat, 18 Feb 2012 13:12:26
> To: How to use LiveCode<[hidden email]>
> Reply-To: How to use LiveCode <[hidden email]>
> Subject: Re: Recreating a binary stack from xml text
>
> Hi Mark,
> Thanks for the update.  Like several other people, I'm really frustrated by
> the non-opertaion of revOnline.  I understand that the team has a lot on
> their hands right now but the thing has been broken for months as far as I
> can tell.  Maybe we should open a community Dropbox or Box.net account that
> allows us all to share useful stacks.
>
> Back to the topic.
>
> I've been thinking about doing something along these lines but haven't had
> a chance to actually do anything other than think about the concept.  Most
> of the posts I've seen about this topic seem to base the solution on XML
> but I'm thinking of using an sqlite database.  What can I say, I'm a
> database guy, I understand them, I don't know much about XML.  Using a DB
> would make it very easy to address the issue you raised regarding
> recreating only part of a stack rather than the whole stack.
>
> If I had the time, I'd like to do this in the context of a version control
> system that would store the info about different versions of a stack and
> allow comparison between versions to see what changed, not just in scripts
> but in any of the stack constructs.  I think that would be a useful and
> fairly straightforward thing to do in the context of a database.  In fact,
> while we're at it, why not add bug tracking capabilties.
>
> Wish I had time to do it.
>
> Pete
>
> On Sat, Feb 18, 2012 at 12:07 PM, Mark Wieder <[hidden email]
> >wrote:
>
> > Pete-
> >
> > Saturday, February 18, 2012, 11:33:51 AM, you wrote:
> >
> > > I saw a post earlier in this thread that perhaps Mark Wieder might be
> > > working on something along these lines.  Mark, can you comment?
> >
> > If revOnline ever comes back (hello rev team?) I'll post a stack that
> > does the translations.
> >
> > Getting to an from xml format isn't that much of a problem technically
> > now that ids are no longer immutable. What's a bit more of a brain
> > teaser is preserving the object hierarchy at the same time. I opted
> > for individual xml files for each control, card, and stack, as well as
> > a project xml file that describes how the objects are organized. That
> > way you can create the entire stack from the xml descriptions or just
> > pick out individual controls and recreate them.
> >
> > Creating an object from the xml description is a matter of looping
> > through the properties, as in
> >
> > -- in a try construct to handle read-only properties
> > try
> >  set the <property> of <object> to <attribute>
> > catch e
> > end try
> >
> > <stack>
> >  <card>
> >  <group>
> >   <control>
> >    <property>
> >    </property>
> >   </control>
> >  </group>
> >  <control>
> >  </control>
> >  </card>
> >  <substack>
> >  ... etc
> >  </substack>
> > </stack>
> >
> > --
> > -Mark Wieder
> >  [hidden email]
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
>
>
> --
> Pete
> Molly's Revenge <http://www.mollysrevenge.com>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

mwieder
In reply to this post by Michael Doub
Mike-

Saturday, February 18, 2012, 2:43:07 PM, you wrote:

> I think the real intent is to get a livecode application into a
> format where you can use standard configuration management tools to
> store versions and track differences.  In theory if the components
> were broken out separately, then you could have multiple people
> working on the same app at the same time.  

Exactly.

> I believe as long as the source is text, then all of source
> management systems that I am aware of will work.  XML is just text
> so it should be fine.  Most of these system can deal with binary
> blobs and they just rev stamp them. So images and media are still
> manageable.  

Nothing particularly special about xml. It's bloated and ugly and
machine-readable rather than human-readable. But it's hierarchical and
it's text, so it's an easy format to deal with. Ideally for LiveCode
purposes you want something that will display the xml storage data as
a nicely formatted tree structure.

> Not having the ability to manage the source code was the only
> thing that prevented me from using livecode in my corporate life.
> So I am excited to hear that others are interested as well.

Yeah, it's a serious drawback.

--
-Mark Wieder
 [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

mwieder
In reply to this post by Michael Chean
Michael-

Saturday, February 18, 2012, 3:16:33 PM, you wrote:

> I've used propietary source code repositories, and I think that
> there is no good argument for them in the small developer shops
> considering the many existing systems out there.

Having rolled my own in the past, I would never go back there again.
Git just does the right thing in the right way.

> I would be very interested in this ability, though I hope that it is
> part of  LiveCode at some point.

Integration into the IDE is very important, although git's integration
into Eclipse is pretty disappointing.

--
-Mark Wieder
 [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Michael Doub
In reply to this post by mwieder
I would prefer something that is easily human readable.  Xml might work as long as the scripts and object properties are presented in a clear and readable enough fashion.

I know that my teams have spent many hours going thru diffs in different version of software looking to find exactly what revision and change introduced a problem.

  -= Mike
 
Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: Mark Wieder <[hidden email]>
Sender: [hidden email]
Date: Sat, 18 Feb 2012 15:37:11
To: How to use LiveCode<[hidden email]>
Reply-To: How to use LiveCode <[hidden email]>
Subject: Re: Recreating a binary stack from xml text

Mike-

Saturday, February 18, 2012, 2:43:07 PM, you wrote:

> I think the real intent is to get a livecode application into a
> format where you can use standard configuration management tools to
> store versions and track differences.  In theory if the components
> were broken out separately, then you could have multiple people
> working on the same app at the same time.  

Exactly.

> I believe as long as the source is text, then all of source
> management systems that I am aware of will work.  XML is just text
> so it should be fine.  Most of these system can deal with binary
> blobs and they just rev stamp them. So images and media are still
> manageable.  

Nothing particularly special about xml. It's bloated and ugly and
machine-readable rather than human-readable. But it's hierarchical and
it's text, so it's an easy format to deal with. Ideally for LiveCode
purposes you want something that will display the xml storage data as
a nicely formatted tree structure.

> Not having the ability to manage the source code was the only
> thing that prevented me from using livecode in my corporate life.
> So I am excited to hear that others are interested as well.

Yeah, it's a serious drawback.

--
-Mark Wieder
 [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

mwieder
In reply to this post by J. Landman Gay
Jacque-

Saturday, February 18, 2012, 12:48:43 PM, you wrote:

> On 2/18/12 2:07 PM, Mark Wieder wrote:

>> If revOnline ever comes back (hello rev team?)

> I haven't been able to view, log in, or anything else on revOnline for a
> while now. Last night I figured it out. It works normally with LiveCode
> 4.x, it breaks completely with LiveCode 5.x.

Glad it's working for you. Here's the error it throws in 4.6.4:

Error in system stack:: handler=revOnlineDecodeArray
 line=802
 char=1
error info= 141,802,22
671,802,7
465,802,1
253,802,1
353,0,0,stack "C:/Program Files/RunRev/LiveCode 4.6.4/Toolset/revonlinelibrary.rev"

and that's a protected system stack, so I can't delve any further into
the problem.

--
-Mark Wieder
 [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Alejandro Tejada
In reply to this post by Geoff Canyon Rev
Hi Geoff,

Many Thanks for sharing this gem!
http://www.quickmeme.com/meme/6o9b/

Geoff Canyon Rev wrote
http://www.inspiredlogic.com/mc/ripper.html
I created mcRipper oh so many years ago. MC = MetaCard
gives you some idea how long ago. As I recall it handled
just about everything, but I haven't touched it in over
ten years. Anyone is free to take a look and laugh at my code.
Actually, it is possible to read your code in the browser :-)
(open the following link in a new tab in your browser)
http://www.inspiredlogic.com/mc/mcripper.mc

Interesting enough, it does not include the ID among
the properties saved as XML:
http://www.inspiredlogic.com/mc/ripperoutput.html

But adding this, and others new properties, should be a
piece of cake for professionals developers in
this platform. ( Not me! :-D )

Just keep wondering if complex grouped controls as
the datagrid could be saved and restored faithfully
using this method.

Ah!...

And now that we are talking about compiling binaries
from text files... Could this method be used via the
Livecode server to create stacks (and download them to
your own computer) using a web text editor
to write the scripts, create controls and their properties?

After this, Livecode will have run the full circle, from
GUI oriented platform to plain Text sources compiled
as binaries. :-D

Al
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

J. Landman Gay
In reply to this post by mwieder
On 2/18/12 7:26 PM, Mark Wieder wrote:

> Glad it's working for you. Here's the error it throws in 4.6.4:
>
> Error in system stack:: handler=revOnlineDecodeArray
>   line=802
>   char=1
> error info= 141,802,22
> 671,802,7
> 465,802,1
> 253,802,1
> 353,0,0,stack "C:/Program Files/RunRev/LiveCode 4.6.4/Toolset/revonlinelibrary.rev"
>
> and that's a protected system stack, so I can't delve any further into
> the problem.

Odd. I was using 4.6.4 when it worked for me last night. I just tried it
again and it still works. Running either 5.02 or the latest pre-release,
the stack opens and just sits there with "loading..." displayed. Nothing
else happens.

Something's borked at any rate.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Geoff Canyon Rev
In reply to this post by Alejandro Tejada
I didn't store the ID because when I wrote it (and for long after that) the
ID was immutable, so there was no need to store it because it couldn't be
set.

That said, I'm guessing that a monolithic XML file is not the way to go
here. Someone who knows git better than I will correct me, but it would be
more useful to store each item as a separate file within a directory
(hierarchy).

I'm tempted to say that there are some things that wouldn't be
worth/necessary to put into version control. Heck, you could start with
just the scripts. So if I'm working on a project with you, we could agree
ahead of time that I'm not in charge of design, but just code. You could
send me a copy of the stack at some point, and an IDE tool would be able to
use basic git commands to refresh/update the scripts of all the objects.
But because we agreed, I know that if I move an object, or create a new
one, or delete one, that won't be captured. Maybe that's not ideal -- if I
find that something is a pixel off, that's a pain not to be able to fix it
right there. But it would be somewhat simpler to implement.

On Sat, Feb 18, 2012 at 8:43 PM, Alejandro Tejada <[hidden email]>wrote:

> Interesting enough, it does not include the ID among
> the properties saved as XML:
> http://www.inspiredlogic.com/mc/ripperoutput.html
>
> But adding this, and others new properties, should be a
> piece of cake for professionals developers in
> this platform. ( Not me! :-D )
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

slylabs13
In reply to this post by Alejandro Tejada
I was going to say that you would have to discriminate between temporary datagrid objects that the datagrid created on the fly, and those that are a part of a datagrid object, but then some people use datagrids as static storage objects, and they would have to be reproduced in their entirety.

Bob


On Feb 18, 2012, at 6:43 PM, Alejandro Tejada wrote:

> Just keep wondering if complex grouped controls as
> the datagrid could be saved and restored faithfully
> using this method.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

slylabs13
In reply to this post by Geoff Canyon Rev
Ick. So easy to lose track that way. Having multiple independent copies of a project floating around is in my opinion to be avoided at all costs. In a real multi-dev system, the control would have to update the existing client copies each time an item was checked out or checked in, so that each user would have as up to date a copy as possible. Ideally, when an item is checked in, each user with something checked out would either get a notification that there were updates, and be allowed to choose to update to the latest revision, or it *could* be done automatically. However, due to the nature of the IDE, you would have to account for running scripts on the client end and not update until an idle time.

It could be done, but it would be complex. I think at the very least, each user would have to checkout a card, and that card and all it's objects would be "locked" for modification by the versioning system. That is where a database would be handy. A system which used both XML for the object descriptions, and a database that kept track of client checkout, object locking and date/time stamping would be ideal.

It seems LC multi-developer systems are trickier than otherwise, because a project is not just code as it would be in a C or Java based system. There are objects which, although typically static, can be altered, and can affect the execution of the code. But if all you cared about was keeping track of changes made, and you didn't care about multi-developer checkout of objects, simply recording changes might be enough.

Bob


On Feb 18, 2012, at 9:07 PM, Geoff Canyon Rev wrote:

> I didn't store the ID because when I wrote it (and for long after that) the
> ID was immutable, so there was no need to store it because it couldn't be
> set.
>
> That said, I'm guessing that a monolithic XML file is not the way to go
> here. Someone who knows git better than I will correct me, but it would be
> more useful to store each item as a separate file within a directory
> (hierarchy).
>
> I'm tempted to say that there are some things that wouldn't be
> worth/necessary to put into version control. Heck, you could start with
> just the scripts. So if I'm working on a project with you, we could agree
> ahead of time that I'm not in charge of design, but just code. You could
> send me a copy of the stack at some point, and an IDE tool would be able to
> use basic git commands to refresh/update the scripts of all the objects.
> But because we agreed, I know that if I move an object, or create a new
> one, or delete one, that won't be captured. Maybe that's not ideal -- if I
> find that something is a pixel off, that's a pain not to be able to fix it
> right there. But it would be somewhat simpler to implement.
>
> On Sat, Feb 18, 2012 at 8:43 PM, Alejandro Tejada <[hidden email]>wrote:
>
>> Interesting enough, it does not include the ID among
>> the properties saved as XML:
>> http://www.inspiredlogic.com/mc/ripperoutput.html
>>
>> But adding this, and others new properties, should be a
>> piece of cake for professionals developers in
>> this platform. ( Not me! :-D )
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Recreating a binary stack from xml text

Geoff Canyon Rev
Agreed that a full implementation would be better; I'm just saying that, compared to the present setup, where there is no source control whatsoever, a system that at least allowed merging code in a controlled fashion would be a huge improvement.

I would hope we can do better than card-level locking, but better that than nothing at all.

Sent from my iPad

On Feb 20, 2012, at 11:51 AM, Bob Sneidar <[hidden email]> wrote:

> Ick. So easy to lose track that way. Having multiple independent copies of a project floating around is in my opinion to be avoided at all costs. In a real multi-dev system, the control would have to update the existing client copies each time an item was checked out or checked in, so that each user would have as up to date a copy as possible. Ideally, when an item is checked in, each user with something checked out would either get a notification that there were updates, and be allowed to choose to update to the latest revision, or it *could* be done automatically. However, due to the nature of the IDE, you would have to account for running scripts on the client end and not update until an idle time.
>
> It could be done, but it would be complex. I think at the very least, each user would have to checkout a card, and that card and all it's objects would be "locked" for modification by the versioning system. That is where a database would be handy. A system which used both XML for the object descriptions, and a database that kept track of client checkout, object locking and date/time stamping would be ideal.
>
> It seems LC multi-developer systems are trickier than otherwise, because a project is not just code as it would be in a C or Java based system. There are objects which, although typically static, can be altered, and can affect the execution of the code. But if all you cared about was keeping track of changes made, and you didn't care about multi-developer checkout of objects, simply recording changes might be enough.
>
> Bob
>
>
> On Feb 18, 2012, at 9:07 PM, Geoff Canyon Rev wrote:
>
>> I didn't store the ID because when I wrote it (and for long after that) the
>> ID was immutable, so there was no need to store it because it couldn't be
>> set.
>>
>> That said, I'm guessing that a monolithic XML file is not the way to go
>> here. Someone who knows git better than I will correct me, but it would be
>> more useful to store each item as a separate file within a directory
>> (hierarchy).
>>
>> I'm tempted to say that there are some things that wouldn't be
>> worth/necessary to put into version control. Heck, you could start with
>> just the scripts. So if I'm working on a project with you, we could agree
>> ahead of time that I'm not in charge of design, but just code. You could
>> send me a copy of the stack at some point, and an IDE tool would be able to
>> use basic git commands to refresh/update the scripts of all the objects.
>> But because we agreed, I know that if I move an object, or create a new
>> one, or delete one, that won't be captured. Maybe that's not ideal -- if I
>> find that something is a pixel off, that's a pain not to be able to fix it
>> right there. But it would be somewhat simpler to implement.
>>
>> On Sat, Feb 18, 2012 at 8:43 PM, Alejandro Tejada <[hidden email]>wrote:
>>
>>> Interesting enough, it does not include the ID among
>>> the properties saved as XML:
>>> http://www.inspiredlogic.com/mc/ripperoutput.html
>>>
>>> But adding this, and others new properties, should be a
>>> piece of cake for professionals developers in
>>> this platform. ( Not me! :-D )
>>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123