1. routine_id() is not working
- Posted by useless_ Apr 10, 2013
- 1548 views
See: http://openeuphoria.org/pastey/208.wc
1) As is, routine_id() always returns -1
2) routine_id() is in os.e , but if you delete the include...os.e line, the routine_id() still "works", but always returns 1
3) If you remove either of the top two include lines, the routine_id() will work properly.
What's up with that?
useless
2. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 10, 2013
- 1547 views
See: http://openeuphoria.org/pastey/208.wc
1) As is, routine_id() always returns -1
2) routine_id() is in os.e , but if you delete the include...os.e line, the routine_id() still "works", but always returns 1
3) If you remove either of the top two include lines, the routine_id() will work properly.
What's up with that?
You're mixing the 3.1 standard library with 4.0. There is a sleep() in misc.e and in std/os.e. Both file.e and database.e include misc.e, and of course, all symbols are global, Therefore, routine_id cannot resolve a unique sleep() when std/os.e is included.
Matt
3. Re: routine_id() is not working
- Posted by useless_ Apr 10, 2013
- 1548 views
See: http://openeuphoria.org/pastey/208.wc
1) As is, routine_id() always returns -1
2) routine_id() is in os.e , but if you delete the include...os.e line, the routine_id() still "works", but always returns 1
3) If you remove either of the top two include lines, the routine_id() will work properly.
What's up with that?
You're mixing the 3.1 standard library with 4.0. There is a sleep() in misc.e and in std/os.e. Both file.e and database.e include misc.e, and of course, all symbols are global, Therefore, routine_id cannot resolve a unique sleep() when std/os.e is included.
Matt
Umm, i am running the windows install the way i downloaded it that day, i didn't mix versions.
useless
4. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 10, 2013
- 1524 views
You're mixing the 3.1 standard library with 4.0. There is a sleep() in misc.e and in std/os.e. Both file.e and database.e include misc.e, and of course, all symbols are global, Therefore, routine_id cannot resolve a unique sleep() when std/os.e is included.
Umm, i am running the windows install the way i downloaded it that day, i didn't mix versions.
Here are the include statements in the code you posted:
include "C:\\Euphoria-10-Feb-2013\\include\\database.e" include "C:\\Euphoria-10-Feb-2013\\include\\file.e" include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e"
The 3.1 standard library is in the include directory and the 4.0 library is in include/std. In general, you should use the stuff in include/std for new development. The older stuff is for backwards compatibility with legacy code.
Matt
5. Re: routine_id() is not working
- Posted by useless_ Apr 10, 2013
- 1520 views
You're mixing the 3.1 standard library with 4.0. There is a sleep() in misc.e and in std/os.e. Both file.e and database.e include misc.e, and of course, all symbols are global, Therefore, routine_id cannot resolve a unique sleep() when std/os.e is included.
Umm, i am running the windows install the way i downloaded it that day, i didn't mix versions.
Here are the include statements in the code you posted:
include "C:\\Euphoria-10-Feb-2013\\include\\database.e" include "C:\\Euphoria-10-Feb-2013\\include\\file.e" include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e"
The 3.1 standard library is in the include directory and the 4.0 library is in include/std. In general, you should use the stuff in include/std for new development. The older stuff is for backwards compatibility with legacy code.
Matt
That is not documented on http://openeuphoria.org/docs/std_os.html#_1860_sleep .
Also, searches for gets and value return nothing.
useless
6. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 10, 2013
- 1517 views
The 3.1 standard library is in the include directory and the 4.0 library is in include/std. In general, you should use the stuff in include/std for new development. The older stuff is for backwards compatibility with legacy code.
That is not documented on http://openeuphoria.org/docs/std_os.html#_1860_sleep .
I'm not sure what we'd put there. Still, I didn't immediately find anything talking about the 3.1 to 4.0 transition, which I thought we had. Possibly in the wiki, although the "What's new in 4.0" at the beginning of the manual says, "Euphoria has a brand new standard library consisting of over 800 public members."
Also, searches for gets and value return nothing.
Hmm...looks like a problem with our indexing. Some things changed in the way the documentation was built, and it looks like the indexing didn't fully make it.
Matt
7. Re: routine_id() is not working
- Posted by useless_ Apr 10, 2013
- 1548 views
The 3.1 standard library is in the include directory and the 4.0 library is in include/std. In general, you should use the stuff in include/std for new development. The older stuff is for backwards compatibility with legacy code.
That is not documented on http://openeuphoria.org/docs/std_os.html#_1860_sleep .
I'm not sure what we'd put there. Still, I didn't immediately find anything talking about the 3.1 to 4.0 transition, which I thought we had. Possibly in the wiki, although the "What's new in 4.0" at the beginning of the manual says, "Euphoria has a brand new standard library consisting of over 800 public members."
I have a further question, since i hadn't considered mixing includes for 3.1 and 4.0 which have the same function names. Lets say i do:
include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e" include "C:\\Euphoria-10-Feb-2013\\include\\misc.e"
(and we can say i did it, because i did it), then i do:
id_num = routine_id("os:sleep") id_num = routine_id("sleep") id_num = routine_id("misc:sleep")
both id_num for sleep and misc:sleep are -1. Of course, this does work:
include "C:\\Euphoria-10-Feb-2013\\include\\misc.e" as misc id_num = routine_id("misc:sleep")
So using namespaces to identify the sleep in misc.e works, but since the sleep in os.e is already namespaced away from misc.e, shouldn't this work too:
include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e" include "C:\\Euphoria-10-Feb-2013\\include\\misc.e" id_num = routine_id("sleep")
This also works:
include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e" as os id_num = routine_id("os:sleep")
even tho os.e is already namespaced internally to itself. So maybe if we get into the habit of always using "as" in includes, or better yet: the interpreter does this automagically, it might make life a lil easier. I think the error msg could get more informative also:
include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e" as os include "C:\\Euphoria-10-Feb-2013\\include\\misc.e" as misc id_num = routine_id("sleep") puts(1,"\n") id_num = routine_id("sleep") -- Error line 3 : pick sleep from os or misc -- Error line 5 : pick sleep from os or misc
Because right now,
include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e" as os include "C:\\Euphoria-10-Feb-2013\\include\\misc.e"
does not error, but the sleep in misc.e is unavailable. Or is that an undocumented feature?
And the reason i appended my question to this as i did is so you can add your answer to the section on namespaces and resolving the mix in the routine_id() section.
useless
8. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 11, 2013
- 1465 views
So using namespaces to identify the sleep in misc.e works, but since the sleep in os.e is already namespaced away from misc.e, shouldn't this work too:
include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e" include "C:\\Euphoria-10-Feb-2013\\include\\misc.e" id_num = routine_id("sleep")
This also works:
include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e" as os id_num = routine_id("os:sleep")
even tho os.e is already namespaced internally to itself.
That's not quite how euphoria namespaces work. The default namespace declared in a file is available for others to use, but is not strictly required, like it is in some languages. It's there as a convenience, but has to be used to make a difference.
So maybe if we get into the habit of always using "as" in includes, or better yet: the interpreter does this automagically, it might make life a lil easier. I think the error msg could get more informative also:
include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e" as os include "C:\\Euphoria-10-Feb-2013\\include\\misc.e" as misc id_num = routine_id("sleep") puts(1,"\n") id_num = routine_id("sleep") -- Error line 3 : pick sleep from os or misc -- Error line 5 : pick sleep from os or misc
I can see a benefit from throwing an error when routine_id returns -1, but this seems like something that could significantly break a lot of code, so we'd probably need a way to toggle this behavior.
Because right now,
include "C:\\Euphoria-10-Feb-2013\\include\\std\\os.e" as os include "C:\\Euphoria-10-Feb-2013\\include\\misc.e"
does not error, but the sleep in misc.e is unavailable. Or is that an undocumented feature?
And the reason i appended my question to this as i did is so you can add your answer to the section on namespaces and resolving the mix in the routine_id() section.
It's a consequence of the way you've included things. You've introduced a conflict in resolving "sleep." You have a namespace that allows you to address one of them, but not the other.
Matt
9. Re: routine_id() is not working
- Posted by petelomax Apr 11, 2013
- 1481 views
since the sleep in os.e is already namespaced away from misc.e,
That's not quite how euphoria namespaces work.
Yes, that "already namespaced away" struck me as a very odd thing to say. My tuppenceworth:
If the compiler finds a conflict, it cannot, repeat CANNOT, arbitrarily pick one of them - or at least would drive you absolutely nuts if it did.
There is no way that a namespace of any kind can somehow make one of them "the default".
A namespace is a qualifier which tells the compiler, explicitly, which one to use when there is such a conflict. No more, no less.
I can see a benefit from throwing an error when routine_id returns -1, but this seems like something that could significantly break a lot of code, so we'd probably need a way to toggle this behavior.
Agreed. I would suggest either:
id = routine_id("sleep") if id=-1 then puts(1,get_last_routine_id_error_description()) ?9/0 end if
or add a new optional parameter
id = routine_id("sleep",fail_on_error:=True)
Pete
10. Re: routine_id() is not working
- Posted by useless_ Apr 11, 2013
- 1459 views
since the sleep in os.e is already namespaced away from misc.e,
That's not quite how euphoria namespaces work.
Yes, that "already namespaced away" struck me as a very odd thing to say. My tuppenceworth:
If the compiler finds a conflict,
But the thing is, the way Matt explained it, there is a conflict, and no error was thrown. The sleep in os could be referred to as os:sleep, but it was still in the same namespace as misc's sleep.
No error was thrown when the two files both included a sleep, and none was thrown when routine_id() was used on sleep.
So i also suggested, and maybe to limit the scope of the post i shouldn't have, mentioned it might be more helpful for the crash-on-start to list the routine_id(sleep) lines when it found two sleeps in the same namespace.
useless
11. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 11, 2013
- 1453 views
since the sleep in os.e is already namespaced away from misc.e,
That's not quite how euphoria namespaces work.
Yes, that "already namespaced away" struck me as a very odd thing to say. My tuppenceworth:
If the compiler finds a conflict,
But the thing is, the way Matt explained it, there is a conflict, and no error was thrown. The sleep in os could be referred to as os:sleep, but it was still in the same namespace as misc's sleep.
No error was thrown when the two files both included a sleep, and none was thrown when routine_id() was used on sleep.
Pete's explanation was a little odd, too, in that he referred to the compiler. A routine_id call is entirely handled at runtime. So it's really the interpreter dealing with this at runtime. The error is returned as -1 (albeit without much help at figuring out why).
So i also suggested, and maybe to limit the scope of the post i shouldn't have, mentioned it might be more helpful for the crash-on-start to list the routine_id(sleep) lines when it found two sleeps in the same namespace.
We could add warnings, perhaps, for routine_id calls with literals that we know cannot be resolved. Since you can dynamically build the name of the routine, we obviously cannot do this for all calls to routine_id.
Matt
12. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 11, 2013
- 1427 views
No error was thrown when the two files both included a sleep,
No error should be thrown here!!! The whole point of namespaces - this shouldn't be an error!
and none was thrown when routine_id() was used on sleep.
This should be optional. There are cases when you want to just let the code continue when routine_id() can't figure things out, but other times you do want an error to be thrown to catch this bug.
I'm quite partial to Pete's optional parameter idea for this.
So i also suggested it might be more helpful for the crash-on-start to list the routine_id(sleep) lines when it found two sleeps in the same namespace.
If the user specifies that routine_id() should crash, then yes! I fully agree with this.
, and maybe to limit the scope of the post i shouldn't have, mentioned
I'd agree with this principle in general, but I disagree with this particular instance. It's too relevant to the topic at hand to be ignored.
13. Re: routine_id() is not working
- Posted by useless_ Apr 11, 2013
- 1408 views
No error was thrown when the two files both included a sleep,
No error should be thrown here!!! The whole point of namespaces - this shouldn't be an error!
So if i write an include with a sleep proceedure in it, and then i include it and misc.e, no error should be thrown? This should not be a problem?
include sleep.e include misc.e
Why shouldn't this generate an error report?
useless
14. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 11, 2013
- 1411 views
So if i write an include with a sleep proceedure in it, and then i include it and misc.e, no error should be thrown? This should not be a problem?
include sleep.e include misc.e
Why shouldn't this generate an error report?
Because there are no errors in that code.
Now, try calling sleep without qualifying it. That's an error, because there is no way to tell which one you really wanted to call.
Matt
15. Re: routine_id() is not working
- Posted by useless_ Apr 11, 2013
- 1439 views
So if i write an include with a sleep proceedure in it, and then i include it and misc.e, no error should be thrown? This should not be a problem?
include sleep.e include misc.e
Why shouldn't this generate an error report?
Because there are no errors in that code.
Now, try calling sleep without qualifying it. That's an error, because there is no way to tell which one you really wanted to call.
Matt
By itself, from the 4ft pov, true, no error as Euphoria is now. But Euphoria still put two sleeps into the same namespace, and it had to include both sleeps in the run code, because of routine_id() being called. In this example, neither sleep is namespaced.
Had i included os.e also, there'd be 3 sleep()s in the same namespace, and the program would happily begin running and not crash untill the program executed a routine_id(sleep), maybe hours later, with data loss. Come on Matt, surely Euphoria can be smarter than that.
useless
16. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 11, 2013
- 1391 views
By itself, from the 4ft pov, true, no error as Euphoria is now. But Euphoria still put two sleeps into the same namespace, and it had to include both sleeps in the run code, because of routine_id() being called. In this example, neither sleep is namespaced.
Actually, that depends on the contents of sleep.e - which isn't either a 3.1 or 4.0 include file.
Had i included os.e also, there'd be 3 sleep()s in the same namespace,
Actually, the one in os.e would be in os.e's default namespace.
and the program would happily begin running and not crash untill the program executed a routine_id(sleep), maybe hours later, with data loss. Come on Matt, surely Euphoria can be smarter than that.
It would not, as currently, routine_id(sleep) (assuming sleep is a variable containing the string "sleep") returns -1 instead of crashing. No crash, no data loss.
17. Re: routine_id() is not working
- Posted by useless_ Apr 11, 2013
- 1346 views
By itself, from the 4ft pov, true, no error as Euphoria is now. But Euphoria still put two sleeps into the same namespace, and it had to include both sleeps in the run code, because of routine_id() being called. In this example, neither sleep is namespaced.
Actually, that depends on the contents of sleep.e - which isn't either a 3.1 or 4.0 includ
I had previously said, in reponce to a post by you in this thread:
So if i write an include with a sleep proceedure in it, and then i include it and misc.e, no error should be thrown? This should not be a problem?
Had i included os.e also, there'd be 3 sleep()s in the same namespace,
Actually, the one in os.e would be in os.e's default namespace.
It's also in "no namespace", you can call it without specifying os:sleep.
and the program would happily begin running and not crash untill the program executed a routine_id(sleep), maybe hours later, with data loss. Come on Matt, surely Euphoria can be smarter than that.
It would not, as currently, routine_id(sleep) (assuming sleep is a variable containing the string "sleep") returns -1 instead of crashing. No crash, no data loss.
Only if i always wrote code to catch the -1 returned from routine_id() (even when i KNOW there is a procedure of the name i am routine_id'ing), which to me is like saying "i know Eu is going to overlook an ambiguous situation at compile time and crash during runtime...". So i suggest AGAIN that Euphoria alert of the ambiguilty before it runs instead of wasting all the runtime before the inevitable crash. It's not terribly reasonable to read the entirety of every include file and compare to every other include file, to check for duplicates procedure names, and not even Euphoria is alerting to this happening until that name is called in the program during runtime.
useless
18. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 11, 2013
- 1393 views
By itself, from the 4ft pov, true, no error as Euphoria is now. But Euphoria still put two sleeps into the same namespace, and it had to include both sleeps in the run code, because of routine_id() being called. In this example, neither sleep is namespaced.
Actually, that depends on the contents of sleep.e - which isn't either a 3.1 or 4.0 include file.
I had previously said, in reponce to a post by you in this thread:
So if i write an include with a sleep proceedure in it, and then i include it and misc.e, no error should be thrown? This should not be a problem?
Well, I suppose it depends on the contents of that include.
Had i included os.e also, there'd be 3 sleep()s in the same namespace,
Actually, the one in os.e would be in os.e's default namespace.
It's also in "no namespace", you can call it without specifying os:sleep.
Good point. Perhaps, in the case where there's a routine with a namespace and a routine without one, routine_id() should choose the routine without the namespace.
and the program would happily begin running and not crash untill the program executed a routine_id(sleep), maybe hours later, with data loss. Come on Matt, surely Euphoria can be smarter than that.
It would not, as currently, routine_id(sleep) (assuming sleep is a variable containing the string "sleep") returns -1 instead of crashing. No crash, no data loss.
Only if i always wrote code to catch the -1 returned from routine_id() (even when i KNOW there is a procedure of the name i am routine_id'ing), which to me is like saying "i know Eu is going to overlook an ambiguous situation at compile time and crash during runtime...". So i suggest AGAIN that Euphoria alert of the ambiguilty before it runs instead of wasting all the runtime before the inevitable crash. It's not terribly reasonable to read the entirety of every include file and compare to every other include file, to check for duplicates procedure names, and not even Euphoria is alerting to this happening until that name is called in the program during runtime.
That's a good point. Adding better lint-type help is always a good idea imvho. I think this makes sense as a warning emitted by eui -test.
19. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 11, 2013
- 1308 views
So if i write an include with a sleep proceedure in it, and then i include it and misc.e, no error should be thrown? This should not be a problem?
include sleep.e include misc.e
Why shouldn't this generate an error report?
Because there are no errors in that code.
Now, try calling sleep without qualifying it. That's an error, because there is no way to tell which one you really wanted to call.
Matt
By itself, from the 4ft pov, true, no error as Euphoria is now. But Euphoria still put two sleeps into the same namespace, and it had to include both sleeps in the run code, because of routine_id() being called. In this example, neither sleep is namespaced.
I don't know what you mean by two sleeps in the same namespace. You seem to be talking about namespaces as they exist in, say, C++. The routines were in different files. This often happens, especially if you use a lot of 3rd party libraries. It becomes a problem when you want to use them. If you never use them, then there is no problem.
Had i included os.e also, there'd be 3 sleep()s in the same namespace, and the program would happily begin running and not crash untill the program executed a routine_id(sleep), maybe hours later, with data loss. Come on Matt, surely Euphoria can be smarter than that.
Maybe. If you're putting a literal into routine_id, then we could resolve this at parse time. Of course, I'd ask why you're doing that and waiting until hours into run time. Better to do it up front and catch the error early. We've agreed that some optional error checking in routine_id makes sense. I'm not sure what else you're asking for.
Please read up on euphoria namespaces. You don't put something into a namespace. You use a namespace to point at a particular file to disambiguate from a symbol in another file. You may declare a default namespace for a file as a convenience, but again, this isn't some sort of sandbox around the symbols in the file. It's just an easy way to tell euphoria to look at that particular file.
Matt
20. Re: routine_id() is not working
- Posted by useless_ Apr 11, 2013
- 1352 views
Please read up on euphoria namespaces. You don't put something into a namespace. You use a namespace to point at a particular file to disambiguate from a symbol in another file. You may declare a default namespace for a file as a convenience, but again, this isn't some sort of sandbox around the symbols in the file. It's just an easy way to tell euphoria to look at that particular file.
Matt
Ah, the last two sentences are the crux of my misunderstanding. They should be in the manual, at the very top of the namespace section.
However, loading two procedures or function by the same name (and un-namespaced) being legal, but loading variables of the same name (and un-namespaced) isn't, seems wrong, because if the programmer didn't namespace them (include blah.e as blah), one or more of them cannot be used.
I don't read all of win32lib.e or it's many includes, so i might write a procedure of the same name as exists in win32lib. Or perhaps something under std/net (which has happened a few times the last few years). I doubt anyone reads all the proc names in every file they might include to see if that name is already taken.
For that reason, i suggest Euphoria "understand" transparently and automagically that all procedures and functions in includes are now addressable like filename:procname, if the programmer has not manually done so. And if i then include os.e and misc.e and then want to use sleep(), being that it's in two files and i didn't specify which one to use, Euphoria toss an error before it runs, letting me know to choose one.
useless
21. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 12, 2013
- 1293 views
However, loading two procedures or function by the same name (and un-namespaced) being legal, but loading variables of the same name (and un-namespaced) isn't, seems wrong,
It is wrong. Loading variables of the same name (and un-namespaced) is legal.
-- a.e public object ab = 0
-- b.e public object ab = 1
-- main.ex include /dev/shm/a.e include /dev/shm/b.e
because if the programmer didn't namespace them (include blah.e as blah), one or more of them cannot be used.
This makes sense, but on the other hand, there's a good chance that the identifiers with name conflicts won't be used at all in the main program.
I don't read all of win32lib.e or it's many includes, so i might write a procedure of the same name as exists in win32lib. Or perhaps something under std/net (which has happened a few times the last few years). I doubt anyone reads all the proc names in every file they might include to see if that name is already taken.
I doubt anyone uses every sumbol in win32lib.e et al.
For that reason, i suggest Euphoria "understand" transparently and automagically that all procedures and functions in includes are now addressable like filename:procname, if the programmer has not manually done so.
Like peu does?
And if i then include os.e and misc.e and then want to use sleep(), being that it's in two files and i didn't specify which one to use, Euphoria toss an error before it runs, letting me know to choose one.
This already happens...
-- c.e ?-1 include /dev/shm/a.e include /dev/shm/b.e ?0 ?1 ?2 ?3 ?4 ?5 ?6 ?7 ?8 ?9 ? ab
Running that with the earlier examples in this post gives
/dev/shm/c.e:14 <0074>:: Errors resolving the following references: 'ab' (/dev/shm/c.e:14) has been declared more than once. in /dev/shm/a.e in /dev/shm/b.e ? ab ^
22. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 12, 2013
- 1296 views
Please read up on euphoria namespaces. You don't put something into a namespace. You use a namespace to point at a particular file to disambiguate from a symbol in another file. You may declare a default namespace for a file as a convenience, but again, this isn't some sort of sandbox around the symbols in the file. It's just an easy way to tell euphoria to look at that particular file.
Ah, the last two sentences are the crux of my misunderstanding. They should be in the manual, at the very top of the namespace section.
I think you're right. I've inserted this paragraph into the 4.1 manual under namespaces, right at the beginning:
Euphoria namespaces are used to disambiguate between symbols (routines, variables, constants, etc) with the same names in different files. They may be declared as a default namespace in a file for the convenience of the users of that file, or they may be declared at the point where a file is included. Note that unlike namespaces in some other languages, this does not provide a sandbox around the symbols in the file. It is just an easy way to tell euphoria to look for a symbol in a particular file.
However, loading two procedures or function by the same name (and un-namespaced) being legal, but loading variables of the same name (and un-namespaced) isn't, seems wrong, because if the programmer didn't namespace them (include blah.e as blah), one or more of them cannot be used.
That's true. Whenever I write a new file these days, I put a default namespace in. I don't always use them, but when I need to, it's available and easy to put in. The general idea is that you'll get an error as soon as you have a problem, and you can fix it right away.
I don't think that most people (or me, anyways) use routine_id as much as you do. These days, I mainly use it for things like GUI event handlers, or for dispatch in the translator (where a missing routine_id is noticed and an error is thrown). Adding checks when a literal is passed to routine_id would definitely help you (and others).
I don't read all of win32lib.e or it's many includes, so i might write a procedure of the same name as exists in win32lib. Or perhaps something under std/net (which has happened a few times the last few years). I doubt anyone reads all the proc names in every file they might include to see if that name is already taken.
For that reason, i suggest Euphoria "understand" transparently and automagically that all procedures and functions in includes are now addressable like filename:procname, if the programmer has not manually done so. And if i then include os.e and misc.e and then want to use sleep(), being that it's in two files and i didn't specify which one to use, Euphoria toss an error before it runs, letting me know to choose one.
Hmm...that's an interesting idea. It seems like it would have to just be the file name, without any path qualifiers. Maybe even without extension. I suppose that explicit namespaces would override. What to do in the case where a file has a default namespace that clashes with a file name of another file included?
Ugh...I think it seems simpler to say, "just add a namespace to your include directive."
I know you're using 4.1 these days. I think you might be interested in include/euphoria/debug/debug.e. It lets you poke around the symbol table, among other things.
Matt
23. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 12, 2013
- 1281 views
I suppose that explicit namespaces would override. What to do in the case where a file has a default namespace that clashes with a file name of another file included?
Well, default namespaces have this problem as well. There's nothing stopping me from editing eukat's sleep.e and changing the top line to 'namespace stdseq'.
24. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 12, 2013
- 1272 views
I suppose that explicit namespaces would override. What to do in the case where a file has a default namespace that clashes with a file name of another file included?
Well, default namespaces have this problem as well. There's nothing stopping me from editing eukat's sleep.e and changing the top line to 'namespace stdseq'.
That's true, but adding filenames now could break working code without changing the code. I'm not seeing a lot of benefit in doing this over what we have.
Matt
25. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 12, 2013
- 1291 views
I suppose that explicit namespaces would override. What to do in the case where a file has a default namespace that clashes with a file name of another file included?
Well, default namespaces have this problem as well. There's nothing stopping me from editing eukat's sleep.e and changing the top line to 'namespace stdseq'.
That's true, but adding filenames now could break working code without changing the code. I'm not seeing a lot of benefit in doing this over what we have.
Matt
Same here.
26. Re: routine_id() is not working
- Posted by useless_ Apr 12, 2013
- 1262 views
I suppose that explicit namespaces would override. What to do in the case where a file has a default namespace that clashes with a file name of another file included?
Well, default namespaces have this problem as well. There's nothing stopping me from editing eukat's sleep.e and changing the top line to 'namespace stdseq'.
That's true, but adding filenames now could break working code without changing the code. I'm not seeing a lot of benefit in doing this over what we have.
Matt
Does that happen often now?
useless
27. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 12, 2013
- 1256 views
I suppose that explicit namespaces would override. What to do in the case where a file has a default namespace that clashes with a file name of another file included?
Well, default namespaces have this problem as well. There's nothing stopping me from editing eukat's sleep.e and changing the top line to 'namespace stdseq'.
That's true, but adding filenames now could break working code without changing the code. I'm not seeing a lot of benefit in doing this over what we have.
Matt
Does that happen often now?
I can't say the answer to that, but I do know that this change would in fact break the interpreter (we have multiple files called syncolor, multiple files called error, etc.) For really big projects that use multiple levels of subdirectories to organize files, I'd be suprised if this sort of thing was actually uncommon...
28. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 12, 2013
- 1296 views
I suppose that explicit namespaces would override. What to do in the case where a file has a default namespace that clashes with a file name of another file included?
Well, default namespaces have this problem as well. There's nothing stopping me from editing eukat's sleep.e and changing the top line to 'namespace stdseq'.
That's true, but adding filenames now could break working code without changing the code.
Matt
Menno's peu solved this problem, though I'm not sure if we'd want to adopt it.
Hmm .. there might be other issues. What if someone wanted to include "e.ex" as well as "e.e" ? Or "e!.ex" ? Or "0error.e" ?
29. Re: routine_id() is not working
- Posted by useless_ Apr 12, 2013
- 1239 views
I suppose that explicit namespaces would override. What to do in the case where a file has a default namespace that clashes with a file name of another file included?
Well, default namespaces have this problem as well. There's nothing stopping me from editing eukat's sleep.e and changing the top line to 'namespace stdseq'.
That's true, but adding filenames now could break working code without changing the code.
Matt
Menno's peu solved this problem, though I'm not sure if we'd want to adopt it.
Hmm .. there might be other issues. What if someone wanted to include "e.ex" as well as "e.e" ? Or "e!.ex" ? Or "0error.e" ?
Now you're sounding like a wrongfull-injury lawyer. No matter what you make, someone will work hard enough to get injured by it. You are talking about willfully editing files to re-namespace them, or re-naming them to existing filenames.
useless
30. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 12, 2013
- 1309 views
I suppose that explicit namespaces would override. What to do in the case where a file has a default namespace that clashes with a file name of another file included?
Well, default namespaces have this problem as well. There's nothing stopping me from editing eukat's sleep.e and changing the top line to 'namespace stdseq'.
That's true, but adding filenames now could break working code without changing the code.
Matt
Menno's peu solved this problem, though I'm not sure if we'd want to adopt it.
Hmm .. there might be other issues. What if someone wanted to include "e.ex" as well as "e.e" ? Or "e!.ex" ? Or "0error.e" ?
Now you're sounding like a wrongfull-injury lawyer. You are talking about willfully editing files to re-namespace them, or re-naming them to existing filenames.
The renaming examples were all real. "e!.ex" was the name of the file used by the e! intepreter, an Euphoria runtime interpeter (which broken when 2.4 came out and dynamic including was no longer possible). 0rror.e (or 0rror.c) is actually produced and used by the translator when bootstraping Euphoria itself. "e.ex" and "e.e" were shorthand for backend.e and backend.ex, in euphoria/source.
No matter what you make, someone will work hard enough to get injured by it.
Good point. That's excellent justification for leaving the entire namespace system as-is.
31. Re: routine_id() is not working
- Posted by mattlewis (admin) Apr 12, 2013
- 1242 views
Now you're sounding like a wrongfull-injury lawyer. No matter what you make, someone will work hard enough to get injured by it. You are talking about willfully editing files to re-namespace them, or re-naming them to existing filenames.
Yes, they will. But doing something that we know will cause pain is something that requires significant benefits. I'm just not seeing the benefits here.
Matt
32. Re: routine_id() is not working
- Posted by petelomax Apr 13, 2013
- 1251 views
(which broken when 2.4 came out and dynamic including was no longer possible)
At the risk of sounding petty, it was 2.5 that broke dynamic including.
33. Re: routine_id() is not working
- Posted by jimcbrown (admin) Apr 13, 2013
- 1255 views
(which broken when 2.4 came out and dynamic including was no longer possible)
At the risk of sounding petty, it was 2.5 that broke dynamic including.
Whoops. You're right. Thanks for the correction.
