Re: IDE and libUrl
I'd propose that we do with libURL what we did with the Standalone Builder: have two versions included in the IDE, and use the version appropriate to the engine being used in that session. Can anyone think of a downside to that? For the sake of simplicity I like being able to use one IDE build across all versions of the engine from the time the IDE went open source going forward. There may be a time when that goal is no longer supportable, but as long as it is I think it's worth doing. Any downsides to the approach for libURL proposed here? -- Richard Gaskin I think it is a good idea to have two different versions of libURL available if that is needed to support larger range of engines. The only addition to consider is being able to query the version number of the currently used one. May be it is already supported. This actually could be a common feature of all components (mainstacks as well as substacks) of IDE. In my opinion, aside from the overall release number, each component should have its own version number. Rather than creating a function for this, we could agree on all stacks having a custom property, for example, mcStackVersion, that could be queried by whatever means one desires. If we want to be more sophisticated, we could have a set with version, date, author, changes. By the way, when implementing both versions, are we going to have libURL inited at startup now or the current practice of each urlLib call librarizing it again will continue? The copy I got lately from Chipp is an installer with separate buttons for Rev and MC, so patching the code with missing libraryStack handler could be done in the installer. I am sure the author will agree with that. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
On 8 Sep 2004, at 03:17, Richard Gaskin wrote: Some time ago Dave Cragg wrote: The version of libUrl (1.1a3) currently being distributed with the Rev 2.5 beta (engine 2.6.1) is not backwards compatible with earlier engines. This is because of syntax added to support secure sockets in https URLs. Can older versions of libURL be used with newer engines (without support for new features, of course)? Yes. I'd propose that we do with libURL what we did with the Standalone Builder: have two versions included in the IDE, and use the version appropriate to the engine being used in that session. Can anyone think of a downside to that? For the sake of simplicity I like being able to use one IDE build across all versions of the engine from the time the IDE went open source going forward. There may be a time when that goal is no longer supportable, but as long as it is I think it's worth doing. Any downsides to the approach for libURL proposed here? I guess there will be a naming issue with the stack. (start using ???) The other issue I'm not so sure about is the potential syntax error when using the newer libUrl with an older engine. (The problem syntax is open secure socket ...) I'm not sure exactly when/if the engine tries to compile loaded stacks. If compiling is only done when a stack is actually called (e.g. after a start using) then it may be OK. But if all substacks in memory are subject to script compilation, then there may be a problem. (I guess I could check this out. :)) A thought. (Apologies if this is what you had in mind.) One approach might be to make the libUrl stack simply a loader stack, with a single libraryStack handler. The two functional versions of libUrl would be held in custom properties. The libraryStack handler would unpackage the appropriate custom property and start using that stack. I just checked if this is feasible, and it seems to be. Although it seems you can't use start using directly on a custom property, you can go to a custom property. So something like this might work: on libraryStack if libUrl_ is not in the stacksInUse then if versionLessThan(2.6.1) then go invisible stack (the cLibUrl1_0_15 of me) ##contains stack libUrl_1_0_15 start using libUrl_1_0_15 close stack libUrl_1_0_15 else go invisible stack (the cLibUrl1_1 of me) start using libUrl_1_1 close stack libUrl_1_1 end if end if end libraryStack function versionLessThan pTarget put the version into tCurV set the itemDel to . put 0 into tCount repeat for each item tNum in pTarget add 1 to tCount if item tCount of tCurV tNum then return true end repeat return false end versionLessThan A problem here might be the size of the libUrl stack that has to be carried around, but I guess the custom properties could be compressed. Too complicated?? By the way, I just noticed that the libUrl pages on the new Rev website are incomplete (no links to documentation or downloads). I'll check with RunRev what they plan for this. However, it may be a good idea to have the latest updaters posted elsewhere. On the Yahoo site perhaps, along with the IDE. Or should I put together a separate download site? (or both?). Cheers Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Controll browser
Hi MetaCarders, did someone also notice this? Looks like some controls do not appear correctly in the Control Browser... Some objects appear indented as if they are part of a group on the same card... But they aren't of course... Small screenshot can be found here: http://www.major-k.de/controlb1.jpg Player display is NOT part of the group hintergrund but looks like in the CB I think i noticed this first with the new 2.5 RR engine, but this might coincidence... Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de P.S. About 50 downloads of my 2lz3 tool-palette so far! Thank you folks and don't forget: Feedback very welcome and appreciated ;-) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Control browser
Hi Jaqueline, ... For what it's worth, I've never seen this behavior, and I use the control browser all the time. I'm running the 2.5r2 engine right now; haven't had time yet to install the latest. Klaus, which new 2.5 do you mean, the first one released a couple of days ago, or the next one that is currently in testing by the use-rev list? I use the first final version of 2.5, not tested with the latest/next one... Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com Best Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
Dave, Let me know if you need a place to host libURL. I've got plenty of server space. -Chipp Dave Cragg wrote: On 8 Sep 2004, at 03:17, Richard Gaskin wrote: Some time ago Dave Cragg wrote: The version of libUrl (1.1a3) currently being distributed with the Rev 2.5 beta (engine 2.6.1) is not backwards compatible with earlier engines. This is because of syntax added to support secure sockets in https URLs. Can older versions of libURL be used with newer engines (without support for new features, of course)? Yes. I'd propose that we do with libURL what we did with the Standalone Builder: have two versions included in the IDE, and use the version appropriate to the engine being used in that session. Can anyone think of a downside to that? For the sake of simplicity I like being able to use one IDE build across all versions of the engine from the time the IDE went open source going forward. There may be a time when that goal is no longer supportable, but as long as it is I think it's worth doing. Any downsides to the approach for libURL proposed here? I guess there will be a naming issue with the stack. (start using ???) The other issue I'm not so sure about is the potential syntax error when using the newer libUrl with an older engine. (The problem syntax is open secure socket ...) I'm not sure exactly when/if the engine tries to compile loaded stacks. If compiling is only done when a stack is actually called (e.g. after a start using) then it may be OK. But if all substacks in memory are subject to script compilation, then there may be a problem. (I guess I could check this out. :)) A thought. (Apologies if this is what you had in mind.) One approach might be to make the libUrl stack simply a loader stack, with a single libraryStack handler. The two functional versions of libUrl would be held in custom properties. The libraryStack handler would unpackage the appropriate custom property and start using that stack. I just checked if this is feasible, and it seems to be. Although it seems you can't use start using directly on a custom property, you can go to a custom property. So something like this might work: on libraryStack if libUrl_ is not in the stacksInUse then if versionLessThan(2.6.1) then go invisible stack (the cLibUrl1_0_15 of me) ##contains stack libUrl_1_0_15 start using libUrl_1_0_15 close stack libUrl_1_0_15 else go invisible stack (the cLibUrl1_1 of me) start using libUrl_1_1 close stack libUrl_1_1 end if end if end libraryStack function versionLessThan pTarget put the version into tCurV set the itemDel to . put 0 into tCount repeat for each item tNum in pTarget add 1 to tCount if item tCount of tCurV tNum then return true end repeat return false end versionLessThan A problem here might be the size of the libUrl stack that has to be carried around, but I guess the custom properties could be compressed. Too complicated?? By the way, I just noticed that the libUrl pages on the new Rev website are incomplete (no links to documentation or downloads). I'll check with RunRev what they plan for this. However, it may be a good idea to have the latest updaters posted elsewhere. On the Yahoo site perhaps, along with the IDE. Or should I put together a separate download site? (or both?). Cheers Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
Dave wrote: By the way, I just noticed that the libUrl pages on the new Rev website are incomplete (no links to documentation or downloads). I'll check with RunRev what they plan for this. However, it may be a good idea to have the latest updaters posted elsewhere. On the Yahoo site perhaps, along with the IDE. Or should I put together a separate download site? (or both?). I'll happily maintain a copy with docs at the MC IDE home page: http://groups.yahoo.com/group/MC_IDE/ -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
