generateUUID

[monte]

I would like to move _internal call "generate_uuid" to an engine function or command. I've got apps I could drop this straight in and I'm positive others do too. I note theres an open Todo for implementing this on linux where libuuid isn't installed. That's possibly a bigger commitment than I'm prepared to make unless you have an idea on that... read from /proc/sys/kernel/random/uuid ?

As for syntax either of these seems to work:

Code: Select all

generate UUID
put it into tUUID

or

Code: Select all

put generateUUID() into tUUID

I played with the notion of extending the random syntax but given UUIDs aren't actually random I'm not convinced it's the best idea.

I think I like `create` as the verb better than `generate` too... It's more xTalkish...

[LCMark]

I always thought 'a new uuid' was good syntax for uuid generation (but that might be a bit tricky to integrate with the current parser).

The reason this never got to the point of being an engine feature was the Linux issue (although it has been some time since we evaluated this). Windows and Mac have functions built in to the system to generate UUID whereas there didn't seem to be a universal solution for Linux.

As an IDE-only '_internal' feature, its scope of usage is very small (indeed, I'm not sure its used at all in the IDE any more)... As an full engine feature it has to work reliably on all platforms and in particular across a wide range of Linux distributions.

[LCMark]

Looks like it might be possible to integrate libuuid as a statically linked library - which solve the Linux issue.

That still leaves iOS and Android though

[malte]

Which type of UUID does that generate? I am currently using a liveCode library by the late Mark Smith that generates type 3 and type 4 UUIDs which both I do need in projects. I would love to be able to have an engine call for that, as both have their uses for me.

Cheers,

Malte

[monte]

Hmm.. I'd forgotten about mobile... would you only accept the pull request if it's implemented on mobile too... doesn't look complicated for iOS... haven't looked at at android? Could be a bigger job than I thought...

Wouldn't LGPL be out of bounds due to the Commercial License? As in you would need to provide a way to relink against a modified library I think...

Malte I'll let Mark answer the type question because he implemented it so he might remember... otherwise I'll look at the implementation and work it out. It's a different api on each platform...

[LCMark]

Ideally features that are added (if not platform-specific) are implemented on all platforms, yes.

I found a libuuid at ossp (website) when searching earlier - although haven't looked into it any depth. That appears have the uuid generation implementation under a very weak license so might be ripe for inclusion. If suitable, this could potentially be used for uuid generation on all platforms.

Android seems to have UUID generation facilities in java.util.UUID.

In terms of what the current function generates - I'm not sure of the type... But that does raise another question, do we need to provide the ability to generate different types? And also, what implementations can provide the options we might want?

[mwieder]

I always thought 'a new uuid' was good syntax for uuid generation (but that might be a bit tricky to integrate with the current parser).

I'd love the "new" syntax to be extendable, not just for uuids, but paving the way for collections and classes.
But I don't know how that would fit in with the Open Language proposal or what changes would be required in the parser.

I'm agnostic about the type of uuids generated. I would think that one type would be enough, but Malte seems to have found a need for more than one, so perhaps an optional parameter would do the trick. I do think, though, that we're going to need uuids as engine-generated properties of objects ( the id/uuid proposal that Monte has put forth) and that whatever type of uuid this is, it should be consistent across all platforms.

[mwieder]

libuuid is part of util-linux and comes with a BSD-3 distribution license. LC could link to it as a git submodule.

libuuid on github:
https://github.com/karelzak/util-linux/ ... er/libuuid

util-linux:
https://www.kernel.org/pub/linux/utils/util-linux/

[monte]

There must be two then because the one I looked at last night was definitely dual GPL LGPL. I'll look at this one. I had to jump through a few hoops to submit resolve image on master so when you get a chance mark could you open a develop branch and merge in the config changes that are on 6.0.1? I ended up ha one to work on a branch off release then copy my changes and delete the branch and create a new branch off master.

Also I'm finding the config and project diffs I need to make to get it to compile a little annoying because I need to remake them for each branch. Not sure what the answer is there.

[malte]

In terms of what the current function generates - I'm not sure of the type... But that does raise another question, do we need to provide the ability to generate different types? And also, what implementations can provide the options we might want?

Hi Mark,

if you look at a UUID generated by the _internal call (never used it, so I do not know) it will have one digit that is always the same. That one indicates the version:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Where it reads M, the version is represented.

For the project I am working with UUIDs, I am using both version 3 and version 4 UUIDs. The advantage of a version 3 UUID, which is based on a MD5 Hash, is that it can be reconstructed programatically from a string, which proves to be quite useful in database searches. I also use version 4 (pseudo random) for different scenarios in a database.

Maybe this WIKIPEDIA entry might be useful:

http://en.wikipedia.org/wiki/Universall ... d_versions

Cheers,

Malte

[monte]

Here's one from OS X...

86C7D0D8-2D0F-4574-9046-F6C8E80E008B

So I guess it's random.

I'm going to recommend looking at the boost uuid library. I guess I'll need Mark/RunRev to make a decision on the library before I do anything on this. Boost libraries look great and the license doesn't require attribution in a compiled app which is nice: http://en.wikipedia.org/wiki/Boost_Software_License. It also implements types 4 & 5. Wikipedia states that type 5 is preferred over 3 for namespace uuids because md5 is compromised.

Syntax suggestion:

Code: Select all

create UUID [with namespace theNamespace]

@mwieder I'm not sure what you mean by `a new uuid`.. create a new uuid? I don't think it would be difficult to do because you just skip those tokens but is it unnecessarily verbose? If we could do something like this it would be nice:

Code: Select all

put a new UUID [with namespace theNamespace] into theUUID

But yes I think that would be difficult with the current parser because it seems to handle only `the` as function prefix... which of course changes the way you parse the script. We could overload `a` but that would be a mess I think... We could just implement as a function createUUID or newUUID for now and use the `a new` syntax when open language is here... I actually would prefer it to be a function... I think we will miss functions if open language does away with them...

[mwieder]

There may also be cases dealing with interfacing with other applications that require uuids in one or another specific form, so specifying the type would be necessary.

And actually uuid() should work fine as a function name.

Code: Select all

put uuid(5) into theUUID

...if I'm not mistaken, current "create" is a synonym for "new", i.e., these two are the same thing:

Code: Select all

new button
create button

[monte]

Hmm... not all libraries support all types. boost for example appears to only support type 4 and 5. If that's all we implemented then defaulting to random if people didn't provide a namespace would be sufficient. If we had more types we would probably need `of type X` syntax I guess. I agree that just uuid as a function name could be sufficient. If it's type 5 then you would need a namespace. Type 4 doesn't need any params so should be the default.

Regarding new... yes... but I was assuming `a new UUID` would be more like a function rather than a command which would be just `new UUID`

[mwieder]

Regarding new

Agreed. I'd rather see uuid be a function myself.

[monte]

I've got a sneaking suspicion that open language intends to do away with functions in the engine... not positive on that though