Re: Exploring A Single File Deploy on Windows

2017-06-23 Thread Bob Sneidar via use-livecode 
I've got a really, really bad feeling about this...

Bob S


> On Jun 23, 2017, at 10:56 , Dan Friedman via use-livecode 
>  wrote:
> 
> I second this motion!   PLEASE!   We must have some way to work BEFORE the 
> eternals are loaded.  Furthermore, we should be able to define where the 
> externals will be saved and loaded.  Requiring that externals must be in the 
> same directory as the exe is far to limiting!
> 
> New DataGrids and fancy new features are fine.  But this seems like a core 
> feature that has been overlooked!
> 
> We have to deliver our app in the next few weeks.  I hope LC offers a 
> solution in time!
> 
> -Dan


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Exploring A Single File Deploy on Windows

2017-06-23 Thread Dan Friedman via use-livecode 
I second this motion!   PLEASE!   We must have some way to work BEFORE the 
eternals are loaded.  Furthermore, we should be able to define where the 
externals will be saved and loaded.  Requiring that externals must be in the 
same directory as the exe is far to limiting!

New DataGrids and fancy new features are fine.  But this seems like a core 
feature that has been overlooked!

We have to deliver our app in the next few weeks.  I hope LC offers a solution 
in time!

-Dan


On 2017-06-21 22:47, J. Landman Gay via use-livecode wrote:
> Could you expand on this a little bit? StandaloneSaving/Saved are only
> sent during a build, so I'm not sure how I'd use those to intercept a
> startup message.

Yes but they could be used at standalone building time (probably will
require a little bit of reordering of processes slightly) so stacks
could embed their resources in a stackfile.

> Also, when do the externals actually load? If they load at startup
> before any messages are sent, then won't the externals already be done
> with before the stack receives the startup message?

At present they are bound before the startup message - which is the
problem as there is no opportunity for script to run.

Currently, you can do the suck up and spit out method - you just mustn't
mark the externals as 'included' in the s/b... And then add code to
standaloneSaving / standaloneSaved:

standaloneSaving (to augment your stackfile with what is needed)
create a substack of your mainstack file which contains the externals
you want in custom props
a library stack handler in the substack which spits out and sets the
externals property of itself

standaloneSaved (to reset your stackfile to what it was before)
   delete the substack

Then in the startup handler of your standalone mainstack, 'start using'
the substack if it is present. That should then load the externals which
you've spat out to disk in an appropriate place.

Warmest Regards,

Mark.

--
Mark Waddingham ~ mark at 
livecode.com ~ 
http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Exploring A Single File Deploy on Windows

2017-06-22 Thread Mark Waddingham via use-livecode 

On 2017-06-21 22:47, J. Landman Gay via use-livecode wrote:

Could you expand on this a little bit? StandaloneSaving/Saved are only
sent during a build, so I'm not sure how I'd use those to intercept a
startup message.


Yes but they could be used at standalone building time (probably will 
require a little bit of reordering of processes slightly) so stacks 
could embed their resources in a stackfile.



Also, when do the externals actually load? If they load at startup
before any messages are sent, then won't the externals already be done
with before the stack receives the startup message?


At present they are bound before the startup message - which is the 
problem as there is no opportunity for script to run.


Currently, you can do the suck up and spit out method - you just mustn't 
mark the externals as 'included' in the s/b... And then add code to 
standaloneSaving / standaloneSaved:


standaloneSaving (to augment your stackfile with what is needed)
   create a substack of your mainstack file which contains the externals 
you want in custom props
   a library stack handler in the substack which spits out and sets the 
externals property of itself


standaloneSaved (to reset your stackfile to what it was before)
  delete the substack

Then in the startup handler of your standalone mainstack, 'start using' 
the substack if it is present. That should then load the externals which 
you've spat out to disk in an appropriate place.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Exploring A Single File Deploy on Windows

2017-06-21 Thread Mark Talluto via use-livecode 
> On Jun 21, 2017, at 11:31 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> Since 8, standalones have loaded their externals on startup - so no script 
> runs before the standalone expects them to be where they should. One way to 
> resolve this is to send a message *before* the externals are bound, allowing 
> the 'spit out' solution to work again by intercepting standaloneSaving / 
> Saved and handling an appropriate message on startup.

I am just working on this problem today. I need to be able to spit out the 
needed externals before the engine tries to use them. Otherwise I am getting an 
'Initialization Error' dialog stating 'failed to load external'.


Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.com 

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Exploring A Single File Deploy on Windows

2017-06-21 Thread J. Landman Gay via use-livecode 

On 6/21/17 1:31 PM, Mark Waddingham via use-livecode wrote:
Since 8, standalones have loaded their externals on startup - so no 
script runs before the standalone expects them to be where they should. 
One way to resolve this is to send a message *before* the externals are 
bound, allowing the 'spit out' solution to work again by intercepting 
standaloneSaving / Saved and handling an appropriate message on startup.


Could you expand on this a little bit? StandaloneSaving/Saved are only 
sent during a build, so I'm not sure how I'd use those to intercept a 
startup message.


Also, when do the externals actually load? If they load at startup 
before any messages are sent, then won't the externals already be done 
with before the stack receives the startup message?



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Exploring A Single File Deploy on Windows

2017-06-21 Thread Mark Waddingham via use-livecode 

On 2017-06-21 19:42, Richard Gaskin via use-livecode wrote:

One of the things I liked about SuperCard was that Bill Appleton had
written his own resource fork into his data file format.  This allowed
SC to store any number of data and even code (XCMDs and DFCNs) within
the data fork, without relying on the Mac's old file system resource
fork.


Mac Classic was a decidedly simpler OS than modern OS's...


Would it be worth considering some means of being able to store
externals directly in the stack file?


You mean like storing them in a custom property and spitting them out on 
startup into an appropriate folder (one which the OS clears out at 
appropriate times)?


What magic is dependent on having an external be a separate file on 
disk?


Dynamic linker magic - neither Windows nor Linux (where the 'problem' 
arises) have system APIs which allow shared libraries to be loaded from 
sections of a file. This is quite reasonable from an OS maker's point of 
view - after all, the point of shared libraries is that they can be 
shared.


Admittedly, systems like LiveCode use shared libraries for extensibility 
so the sharing aspect isn't actually all that interesting for this case.


However, the systems which don't have a 'bundle' type abstraction (i.e. 
Windows and Linux) have good stories for installation - there are 
numerous Windows Installer creators, and all Linux distros have their 
own package management system.



Couldn't the entry point for that code be found at least as easily
(and perhaps slightly more efficiently) if stored within the stack
file?


There's a lot more to it than that - a shared library is mostly linked, 
but the OS does a final link step at the point they are loaded. There 
are all kinds of things which go on there - resolution of dependent 
libraries, versioning, rewriting various bits of memory to ensure 
everything references the right addresses, allocated per-thread storage, 
etc.


Whilst it would be possible to do, it would be a huge sink of resources 
to solve a problem which has been solved by the relevant OSes in their 
own way - i.e. installers / packages. It would also be a huge 
maintenance burden - i.e. lets spend our time solving problems which 
haven't already been solved perfectly well.


Since 8, standalones have loaded their externals on startup - so no 
script runs before the standalone expects them to be where they should. 
One way to resolve this is to send a message *before* the externals are 
bound, allowing the 'spit out' solution to work again by intercepting 
standaloneSaving / Saved and handling an appropriate message on startup.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Exploring A Single File Deploy on Windows

2017-06-21 Thread Richard Gaskin via use-livecode 

Dan Friedman wrote:

> With LC 8.1 and later, we’re now using tsNet rather than libURL.
> That’s fine.  However, a Windows standalone that uses tsNet cannot
> even launch unless tsNet.dll is in the same directory as the
> standalone.exe.  This makes deploying a single file on Windows
> impossible.

The others here have offered good suggestions for suck-up-and-spit-out 
solutions to solve the problem for now. but looking ahead:


One of the things I liked about SuperCard was that Bill Appleton had 
written his own resource fork into his data file format.  This allowed 
SC to store any number of data and even code (XCMDs and DFCNs) within 
the data fork, without relying on the Mac's old file system resource fork.


I really really really prefer to deliver truly stand-alone standalones 
whenever practical, but with more and more new features being 
implemented in bundled externals the number of apps I can do this for is 
shrinking with each release.


Would it be worth considering some means of being able to store 
externals directly in the stack file?


What magic is dependent on having an external be a separate file on disk?

Couldn't the entry point for that code be found at least as easily (and 
perhaps slightly more efficiently) if stored within the stack file?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Exploring A Single File Deploy on Windows

2017-06-19 Thread Roger Eller via use-livecode 
On Mon, Jun 19, 2017 at 3:31 PM, Dan Friedman via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Greetings…
>
> With LC 8.1 and later, we’re now using tsNet rather than libURL.  That’s
> fine.  However, a Windows standalone that uses tsNet cannot even launch
> unless tsNet.dll is in the same directory as the standalone.exe.  This
> makes deploying a single file on Windows impossible.  Which means you have
> to zip everything up and hope your client double-clicks with correct file,
> or use an installer. Yuck!
>
> Now, we know that we can create a standalone that uses libURL instead of
> tsNet (thank you Matthias, http://lists.runrev.com/
> pipermail/use-livecode/2017-April/236013.html).  But, can you switch
> systems after launch?  If you can, then you could create a standalone that
> uses libURL -- which will launch.  During the app’s startup you could then
> save any DLLs, files or whatever either from custom properties or download
> from the net.  Once all that was done you would then switch to tsNet.  Or,
> even require that the user simply restart the app and it will re-launch and
> use tsNet.
>
> So, when the app launches if it doesn’t find tsNet.dll in the correct
> location, then it continues using libURL and downloads/saves tsNet.  If it
> does find tsNet in the correct location, then it uses tsNet.
>
> What do you think?  Is this possible?
>
>

That is exactly what I would try.

~Roger
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Exploring A Single File Deploy on Windows

2017-06-19 Thread Dan Friedman via use-livecode 
Greetings…

With LC 8.1 and later, we’re now using tsNet rather than libURL.  That’s fine.  
However, a Windows standalone that uses tsNet cannot even launch unless 
tsNet.dll is in the same directory as the standalone.exe.  This makes deploying 
a single file on Windows impossible.  Which means you have to zip everything up 
and hope your client double-clicks with correct file, or use an installer. Yuck!

Now, we know that we can create a standalone that uses libURL instead of tsNet 
(thank you Matthias, 
http://lists.runrev.com/pipermail/use-livecode/2017-April/236013.html).  But, 
can you switch systems after launch?  If you can, then you could create a 
standalone that uses libURL -- which will launch.  During the app’s startup you 
could then save any DLLs, files or whatever either from custom properties or 
download from the net.  Once all that was done you would then switch to tsNet.  
Or, even require that the user simply restart the app and it will re-launch and 
use tsNet.

So, when the app launches if it doesn’t find tsNet.dll in the correct location, 
then it continues using libURL and downloads/saves tsNet.  If it does find 
tsNet in the correct location, then it uses tsNet.

What do you think?  Is this possible?

-Dan
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode