1. Tasks - communication
- Posted by boater Oct 20, 2012
- 1825 views
Started playing around with tasks, which seem to offer a lot of possibilities for programming round parallel activities like long lasting i/o.
Are there any posts/ thoughts on inter-task communications, or messaging, that anyone can point me to?
2. Re: Tasks - communication
- Posted by useless_ Oct 20, 2012
- 1854 views
Started playing around with tasks, which seem to offer a lot of possibilities for programming round parallel activities like long lasting i/o.
Are there any posts/ thoughts on inter-task communications, or messaging, that anyone can point me to?
I was working on this a few years ago, on Eu v4.0b2. I had task-to-task and global broadcasts working, in March 2010. There was a lot of opposition to communication between tasks, so i quit working on it.
which is why i am
useless
3. Re: Tasks - communication
- Posted by boater Oct 20, 2012
- 1854 views
"Opposition"? Because it would lead to problems, or just on some principle?
4. Re: Tasks - communication
- Posted by useless_ Oct 20, 2012
- 1810 views
"Opposition"? Because it would lead to problems, or just on some principle?
I don't remember, and don't want to remember any more.
useless
5. Re: Tasks - communication
- Posted by DerekParnell (admin) Oct 21, 2012
- 1855 views
Started playing around with tasks, which seem to offer a lot of possibilities for programming round parallel activities like long lasting i/o.
Are there any posts/ thoughts on inter-task communications, or messaging, that anyone can point me to?
I was working on this a few years ago, on Eu v4.0b2. I had task-to-task and global broadcasts working, in March 2010. There was a lot of opposition to communication between tasks, so i quit working on it.
Kat, I don't think you are correct with that assertion. Can you tell me exactly what was the opposition you are referring to? And how do you define "a lot of opposition" in this context?
I think that having inter-task communication is imperative, especially for safe access to shared data between tasks.
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
6. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1844 views
Started playing around with tasks, which seem to offer a lot of possibilities for programming round parallel activities like long lasting i/o.
Are there any posts/ thoughts on inter-task communications, or messaging, that anyone can point me to?
I was working on this a few years ago, on Eu v4.0b2. I had task-to-task and global broadcasts working, in March 2010. There was a lot of opposition to communication between tasks, so i quit working on it.
Kat, I don't think you are correct with that assertion. Can you tell me exactly what was the opposition you are referring to? And how do you define "a lot of opposition" in this context?
I think that having inter-task communication is imperative, especially for safe access to shared data between tasks.
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
Ok, force me to think of the depressing events. I think it went something like this: code i contributed for strtok was un-needed, code i contributed for http.e was overwritten, code i was writing for irc.e was recieved with "who needs irc?" and derisions of a mirc clone, and when tasks.e was finalised i was told someone in the dev team would now do taskmsgs.e and my code wasn't worth looking at. My taskmsgs.e worked two years ago. Over two yrs ago i had http.e task-aware, and that contribution was rejected till just last month!
The msgs are tagged with from_who and to_who (and anything else, like origin and expiry times), a task can be polite and query only for it's own id, or it can query for other task id if it knows them (this is unlikely). A global broadcast of a task_msg is simply a msg with all known (known to taskmsgs.e, not necessarily known to each task) task_ids in the to_who field. After a msg is recieved by a task, the msg is deleted from the handler (or for globals, that task's id is deleted from that to_who). Tasks can ask for msgs only from certain id, or get them in order of time sent, or private msgs before globals.
It was a cute piece of code, pretty small too. I was proud of it. I was so stupid to think humans wanted it. Last save was March 13, 2010. I have not looked at it or used it since.
useless
Forked into: Re: Tasks - communication
7. Re: Tasks - communication
- Posted by mattlewis (admin) Oct 21, 2012
- 1954 views
Kat, I don't think you are correct with that assertion. Can you tell me exactly what was the opposition you are referring to? And how do you define "a lot of opposition" in this context?
I think that having inter-task communication is imperative, especially for safe access to shared data between tasks.
I think it sounds like a nice thing to have, too. My recollection was that other issues (mainly how to deal with translated dlls) sidetracked the whole multi-tasking thing. And the messaging was just collateral damage.
Matt
8. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1762 views
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
Seconded.
9. Re: Tasks - communication
- Posted by boater Oct 21, 2012
- 1741 views
Any chance I could see the code - or is it private?
10. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1726 views
Kat, I don't think you are correct with that assertion. Can you tell me exactly what was the opposition you are referring to? And how do you define "a lot of opposition" in this context?
I think that having inter-task communication is imperative, especially for safe access to shared data between tasks.
I think it sounds like a nice thing to have, too. My recollection was that other issues (mainly how to deal with translated dlls) sidetracked the whole multi-tasking thing. And the messaging was just collateral damage.
Matt
Since all my working code right now is running interpreted and not compiled, that wasn't an issue. I wrongly assumed a notice about using tasks.e in compiled code wasn't a problem. I'd have voted, and i think i did, provide the functionality of tasks for interpreted apps and then fix the compiler asap. Instead, tasks were relegated to the back seat and there's still issues regarding dlls even without tasks.
I seem to remember too that since i used simple (barely) linked lists instead of maps.e, anything i wrote was going to be gutted merely to use maps. Including maps was going to eat more computer resourses than any gain to be had, but using the newfangled maps was more important consideration than my existing work, than my decision to go with a couple of simple linked lists. I felt lower than dirt, i gave up. It was one of those straws on the proverbial camel.
useless
11. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1720 views
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
Seconded.
Global broadcasts between tasks ate more cpu clocks than narrowcasting. It increased the msg queue for each task, and the overhead in tracking which msgs got delivered and could be deleted to free memory. Memory use sounds trivial until you consider the size of msgs that could have been sent from http.e, for instance.
So i provided for broad- and narrow- casting. You choose your best option for the app you are currently coding. Sue me.
useless
12. Re: Tasks - communication
- Posted by EUWX Oct 21, 2012
- 1721 views
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
Seconded.
1. I am presuming you all are thinking of ditching Watcom, perhaps to be replace by MinGw/GCC.
This statement regarding "D Programming Language's approach" makes it most desirable to make D the main compiler for Euphoria.
2. Windows XP can only use 3GB. There are good instructions available from Microsoft on how to use memory above 3GB, which may be conveniently used by Euphoria as a shared resource. I don't know if this facility is there in Windows 7 or Windows 8. I doubt it very much.
13. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1729 views
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
Seconded.
Global broadcasts between tasks ate more cpu clocks than narrowcasting. It increased the msg queue for each task, and the overhead in tracking which msgs got delivered and could be deleted to free memory. Memory use sounds trivial until you consider the size of msgs that could have been sent from http.e, for instance.
Agreed. The shared data should be global, rather than duplicated via messaging. It's faster for two threads to use the same block of memory than to have two processes communicate via IPC to notify each other of updates everytime one of the processes touches the object.
Perhaps I'm simply not thinking far enough ahead though - one day we may very well attempt to run multiple threads across different computers (and perhaps different architectures) on a cloud, for example.
So i provided for broad- and narrow- casting. You choose your best option for the app you are currently coding. Sue me.
I suspect that I'd normally choose narrowcasting most of the time, if I had to choose between those two options.
14. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1715 views
1. I am presuming you all are thinking of ditching Watcom, perhaps to be replace by MinGw/GCC.
Not sure what that has to do with this thread.
This statement regarding "D Programming Language's approach" makes it most desirable to make D the main compiler for Euphoria.
D is not C but a different language altogther. I'd be skeptical of this approach unless someone actually takes the time to present a working system using D instead of C as the translator output. A working system that can be tested vigouriously and independantly, I should add.
2. Windows XP can only use 3GB. There are good instructions available from Microsoft on how to use memory above 3MB,
Typo for 3GB?
which may be conveniently used by Euphoria as a shared resource. I don't know if this facility is there in Windows 7 or Windows 8. I doubt it very much.
Perhaps you can save us the trouble by posting a link to these instructions from M$? It's unlikely that it'd be adopted if it doesn't work on later versions of Windoze (let alone a portable approach among different arches, or something that doesn't work on systems with less than 3GB of RAM), but that's up to the dev team.
15. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1677 views
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
Seconded.
Global broadcasts between tasks ate more cpu clocks than narrowcasting. It increased the msg queue for each task, and the overhead in tracking which msgs got delivered and could be deleted to free memory. Memory use sounds trivial until you consider the size of msgs that could have been sent from http.e, for instance.
Agreed. The shared data should be global, rather than duplicated via messaging. It's faster for two threads to use the same block of memory than to have two processes communicate via IPC to notify each other of updates everytime one of the processes touches the object.
While IPC is all fine and all, it makes life difficult for the task msg system to know if all the tasks read it, and to keep them in FIFO order. Ditto sorting them. My global system didn't duplicate the global msg, it merely kept it and updated the to_who based on who did read it. When all the to_who of a msg (one task, or 2 of 5 tasks, or all tasks) got deleted, the msg got deleted. It used no more memory than calling a procedure with the data or assigning it a variable.
Perhaps I'm simply not thinking far enough ahead though - one day we may very well attempt to run multiple threads across different computers (and perhaps different architectures) on a cloud, for example.
I doubt it. I run a cluster, altho it's a lot less useful after the winxp SP that throttled down lan speeds. Decades ago i tried to discuss a Euphoria based RPC for irc bots and Ai, and i think the opinion from everyone was that was illegal. Or it's possibilities were illegal. Or it had the same pitfalls a Microsoft's RPC interface. Or "you're just trying to break into my computer!". The suggestion went nowhere in a hurry. I did link code (written in php on a nix box) on a webserver to Tiggr (written in Euphoria on winxp) for a browser and general http (uploading and downloading and interacting) interface to her, that worked nicely, handshaking and data passing back and forth real neatly and quickly, but also went nowhere.
So i provided for broad- and narrow- casting. You choose your best option for the app you are currently coding. Sue me.
I suspect that I'd normally choose narrowcasting most of the time, if I had to choose between those two options.
If you had to choose? Is this a undue excessive burden? You are not required to choose, you could flip a coin or ignore one option. I didn't want the burden of choosing for you, so i wrote in both options, i thought they'd be useful. Sorry.
useless
16. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1718 views
Agreed. The shared data should be global, rather than duplicated via messaging. It's faster for two threads to use the same block of memory than to have two processes communicate via IPC to notify each other of updates everytime one of the processes touches the object.
While IPC is all fine and all, it makes life difficult for the task msg system to know if all the tasks read it, and to keep them in FIFO order. Ditto sorting them.
Agreed. Hence why I said I didn't want to go this way.
My global system didn't duplicate the global msg, it merely kept it and updated the to_who based on who did read it. When all the to_who of a msg (one task, or 2 of 5 tasks, or all tasks) got deleted, the msg got deleted. It used no more memory than calling a procedure with the data or assigning it a variable.
Sounds like a sound implementation of task messaging to me. One made possible because it's possible to share variables (and implicitly the address space) between tasks.
Going on a tangent:
I misread Derek's original post, however. I think that sharing variables between threads BY DEFAULT is a bad idea. It should be possible to mark a variable as shared between threads, but I feel that having this the default is a bad idea. I feel that this is the source of bugs in many notive multithreaded progrrams.
This is less important for cooperative nonconcurrent tasks, but I don't have a problem with the above principle being applied to tasks as well.
Perhaps I'm simply not thinking far enough ahead though - one day we may very well attempt to run multiple threads across different computers (and perhaps different architectures) on a cloud, for example.
I doubt it. I run a cluster, altho it's a lot less useful after the winxp SP that throttled down lan speeds.
Understood. I'll note your agreement with me then.
Decades ago i tried to discuss a Euphoria based RPC for irc bots and Ai, and i think the opinion from everyone was that was illegal. Or it's possibilities were illegal. Or it had the same pitfalls a Microsoft's RPC interface. Or "you're just trying to break into my computer!". The suggestion went nowhere in a hurry. I did link code (written in php on a nix box) on a webserver to Tiggr (written in Euphoria on winxp) for a browser and general http (uploading and downloading and interacting) interface to her, that worked nicely, handshaking and data passing back and forth real neatly and quickly, but also went nowhere.
All before my time, I guess.
So i provided for broad- and narrow- casting. You choose your best option for the app you are currently coding. Sue me.
I suspect that I'd normally choose narrowcasting most of the time, if I had to choose between those two options.
If you had to choose? Is this a undue excessive burden? You are not required to choose, you could flip a coin or ignore one option. I didn't want the burden of choosing for you, so i wrote in both options, i thought they'd be useful. Sorry.
Although having both choices is useful, having only these two choices to the exclusion of all other possibilities is an undue excessive burden. Having to ignore an option would be an even greater undue excessive burden.
17. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1681 views
So i provided for broad- and narrow- casting. You choose your best option for the app you are currently coding. Sue me.
I suspect that I'd normally choose narrowcasting most of the time, if I had to choose between those two options.
If you had to choose? Is this a undue excessive burden? You are not required to choose, you could flip a coin or ignore one option. I didn't want the burden of choosing for you, so i wrote in both options, i thought they'd be useful. Sorry.
Although having both choices is useful, having only these two choices to the exclusion of all other possibilities is an undue excessive burden. Having to ignore an option would be an even greater undue excessive burden.
I provided for two choices, a global broadcast or a list of tasks to narrowcast to. What other choice could there be? This is what i wrote in early 2010:
-- fromid is always from only one source, the one doing the sending -- toid can be: -- -- atom -- one task -- -- {atom,atom,etc} -- a selection of tasks -- -- "*" -- all tasks except fromid export procedure task_send_var(object toid, atom fromid, object what)
Putting sequences in toid would cause a lan transaction, but i didn't get that far in the code i didn't delete. What code i have remaining is what wasn't deleted.
useless
18. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1757 views
Any chance I could see the code - or is it private?
I did a word search on the system to see if i had any taskmsg code remaining. What i found i don't know the status of, i do not know if it works with Eu versions since late 2009, i don't know if it works with the existing tasks.e. It has no cluster code in it, which is what was in front of me when i began deleting code, and is most certainly gone. Since the current tasks.e doesn't talk across a lan, the taskmsgs.e for the lan wouldn't have helped you anyhow.
I don't know that i want to support it. Just working on it got me kicked in the ribs and my breath knocked out of me, and i have not recovered.
useless
19. Re: Tasks - communication
- Posted by EUWX Oct 21, 2012
- 1760 views
1. I am presuming you all are thinking of ditching Watcom, perhaps to be replace by MinGw/GCC.
Not sure what that has to do with this thread.
I am presuming that you and I are reading the same Euphoria forum, where there is a thread for ditching Watcom.
I am presuming that you understand that it is axiomatic to replace Watcom with another C compiler
I am also aware of your statement regarding your liking the "D Programming Language's approach" towards "Tasks - communication" which I am sure is the title of this thread.
desirable_compiler = (need_for_Tasks_communication & using_D) - watcom_compiler
Hence I am sure that statement has everything to do with this thread.
This statement regarding "D Programming Language's approach" makes it most desirable to make D the main compiler for Euphoria.
D is not C but a different language altogether. I'd be skeptical of this approach unless someone actually takes the time to present a working system using D instead of C as the translator output. A working system that can be tested vigorously and independently, I should add.
D is NOT vastly different from C, and has many desirable features. If you are going to change compilers, there IS GOING TO BE SOME WORK involved.
2. Windows XP can only use 3GB. There are good instructions available from Microsoft on how to use memory above 3GB,
Typo for 3GB?
No Typo.
A regular 32bit os such as windows 7, vista or xp can only ADDRESS 4GB of memory.
Out of that 4GB you have to have room for video memory and some other devices etc.
So if you have 3GB memory installed its fine, but when you have 4GB installed memory some of the memory addresses are used instead for video memory etc. which is why even with 4gb you can only usually use about 3.15-3.25GB in windows 32bit.
which may be conveniently used by Euphoria as a shared resource. I don't know if this facility is there in Windows 7 or Windows 8. I doubt it very much.
Perhaps you can save us the trouble by posting a link to these instructions from M$? It's unlikely that it'd be adopted if it doesn't work on later versions of Windoze (let alone a portable approach among different arches, or something that doesn't work on systems with less than 3GB of RAM), but that's up to the dev team.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366796%28v=vs.85%29.aspx
20. Re: Tasks - communication
- Posted by boater Oct 21, 2012
- 1725 views
Well, that's a shame - it would have been both helpful and interesting to see how you went about this. The little bit of thinking I have achieved for myself so far seems to be not unlike what you described.
But the whole thing was clearly very painful, and I have no desire to put you through that again. I'll carry on with my own (doubtless much cruder) ideas.
21. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1699 views
2. Windows XP can only use 3GB. There are good instructions available from Microsoft on how to use memory above 3MB,
Typo for 3GB?
No Typo.
A regular 32bit os such as windows 7, vista or xp can only ADDRESS 4GB of memory.
Out of that 4GB you have to have room for video memory and some other devices etc.
So if you have 3GB memory installed its fine, but when you have 4GB installed memory some of the memory addresses are used instead for video memory etc. which is why even with 4gb you can only usually use about 3.15-3.25GB in windows 32bit.
That's great, but why
There are good instructions available from Microsoft on how to use memory above 3MB,
useless
22. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1712 views
1. I am presuming you all are thinking of ditching Watcom, perhaps to be replace by MinGw/GCC.
Not sure what that has to do with this thread.
I am presuming that you and I are reading the same Euphoria forum, where there is a thread for ditching Watcom.
Yes. Obviously, that's a different thread.
I am presuming that you understand that it is axiomatic to replace Watcom with another C compiler
No. Why is this the case?
I am also aware of your statement regarding your liking the "D Programming Language's approach" towards "Tasks - communication" which I am sure is the title of this thread.
You presume incorrectly. I am not a fan of the D programming language, nor do I particularly like it. If my personal preference was the only factor involved, D would never be part of Eu.
I never made that statement.
desirable_compiler = (need_for_Tasks_communication & using_D) - watcom_compiler
Hence I am sure that statement has everything to do with this thread.
D is NOT vastly different from C, and has many desirable features. If you are going to change compilers, there IS GOING TO BE SOME WORK involved.
I see you are wrong on all three counts.
If you want to continue discussing this, then I'm going to ask you to make a new thread about adding D support to the Euphoria backend.
2. Windows XP can only use 3GB. There are good instructions available from Microsoft on how to use memory above 3MB,
Typo for 3GB?
No Typo.
In that case, where are these instructions on how to use memory above 3 megabytes?
A regular 32bit os such as windows 7, vista or xp can only ADDRESS 4GB of memory.
Out of that 4GB you have to have room for video memory and some other devices etc.
So if you have 3GB memory installed its fine, but when you have 4GB installed memory some of the memory addresses are used instead for video memory etc. which is why even with 4gb you can only usually use about 3.15-3.25GB in windows 32bit.
I already know this. What does this have to do with special instructions for using memory above 3 megabytes (not 3 gigabytes, which would have made more sense).
which may be conveniently used by Euphoria as a shared resource. I don't know if this facility is there in Windows 7 or Windows 8. I doubt it very much.
Perhaps you can save us the trouble by posting a link to these instructions from M$? It's unlikely that it'd be adopted if it doesn't work on later versions of Windoze (let alone a portable approach among different arches, or something that doesn't work on systems with less than 3GB of RAM), but that's up to the dev team.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366796%28v=vs.85%29.aspx
Ah. PAE is available on all OSes that Eu supports: http://blog.superuser.com/2011/04/23/want-lots-of-ram-stop-using-32-bits/
You don't really need this if you merely want to use memory about 3 megabytes, however.
23. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1696 views
I don't know that i want to support it. Just working on it got me kicked in the ribs and my breath knocked out of me, and i have not recovered.
By who? I'd like to see that person kicked out.
24. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1668 views
I provided for two choices, a global broadcast or a list of tasks to narrowcast to. What other choice could there be? This is what i wrote in early 2010:
-- fromid is always from only one source, the one doing the sending -- toid can be: -- -- atom -- one task -- -- {atom,atom,etc} -- a selection of tasks -- -- "*" -- all tasks except fromid export procedure task_send_var(object toid, atom fromid, object what)
Why not simply:
shared object o
Putting sequences in toid would cause a lan transaction, but i didn't get that far in the code i didn't delete. What code i have remaining is what wasn't deleted.
It sounds like what you have left isn't usable enough to be extended into the official Euphoria task messaging system anyways. Too bad, but life goes on. Someone will (eventually) write one.
25. Re: Tasks - communication
- Posted by jaygade Oct 21, 2012
- 1627 views
Right -- the point wasn't whether to use the D compiler, but rather to take the D approach to tasking. That is, the methodology and/or API used by the D programming languages standard libraries with regards to tasking, not using the D compiler itself.
26. Re: Tasks - communication
- Posted by jaygade Oct 21, 2012
- 1681 views
Oh, and I have zero idea what this has to do with lan management.
27. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1694 views
I provided for two choices, a global broadcast or a list of tasks to narrowcast to. What other choice could there be? This is what i wrote in early 2010:
-- fromid is always from only one source, the one doing the sending -- toid can be: -- -- atom -- one task -- -- {atom,atom,etc} -- a selection of tasks -- -- "*" -- all tasks except fromid export procedure task_send_var(object toid, atom fromid, object what)
Why not simply:
shared object o
In place of, or in addition to, what, exactly? If you mean to simply share an object that's available to all tasks, there is no point in having a task msg manager.
Putting sequences in toid would cause a lan transaction, but i didn't get that far in the code i didn't delete. What code i have remaining is what wasn't deleted.
It sounds like what you have left isn't usable enough to be extended into the official Euphoria task messaging system anyways. Too bad, but life goes on. Someone will (eventually) write one.
Funny, i read that as "ok, your code sucks, it's not good enough for anyone to use, tsk tsk, we can write a new one from scratch without you". But collectively, you said that 2 years ago.
Great reason for me to not share the code with boater. Which i was considering doing.
useless
28. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1675 views
Oh, and I have zero idea what this has to do with lan management.
Yes, who is managing a lan in this thread??
useless
29. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1706 views
I provided for two choices, a global broadcast or a list of tasks to narrowcast to. What other choice could there be? This is what i wrote in early 2010:
-- fromid is always from only one source, the one doing the sending -- toid can be: -- -- atom -- one task -- -- {atom,atom,etc} -- a selection of tasks -- -- "*" -- all tasks except fromid export procedure task_send_var(object toid, atom fromid, object what)
Why not simply:
shared object o
In place of, or in addition to, what, exactly? If you mean to simply share an object that's available to all tasks,
This is exactly what I meant. I wasn't commenting on the task msg manager, just responding to Derek's comment about making variables shared by default.
there is no point in having a task msg manager.
I think that having one is useful, but there are times when simply sharing a variable is enough. Of course, there are times when you want a full fledged manager as well.
If your routine is about messaging, instead of sharing variables, perhaps task_send_msg() is a better name than task_send_var().
Putting sequences in toid would cause a lan transaction, but i didn't get that far in the code i didn't delete. What code i have remaining is what wasn't deleted.
It sounds like what you have left isn't usable enough to be extended into the official Euphoria task messaging system anyways. Too bad, but life goes on. Someone will (eventually) write one.
Funny, i read that as "ok, your code sucks, it's not good enough for anyone to use, tsk tsk, we can write a new one from scratch without you".
I read it the same as the first paragraph that you wrote here: http://openeuphoria.org/forum/119342.wc#119342
I did a word search on the system to see if i had any taskmsg code remaining. What i found i don't know the status of, i do not know if it works with Eu versions since late 2009, i don't know if it works with the existing tasks.e. It has no cluster code in it, which is what was in front of me when i began deleting code, and is most certainly gone. Since the current tasks.e doesn't talk across a lan, the taskmsgs.e for the lan wouldn't have helped you anyhow.
In fact, I based it from your opinion that the code wasn't in a condition to help boater, since, you know, the code that is left isn't available for me to look at.
But collectively, you said that 2 years ago.
Matt agrees with me, that this is not the case. http://openeuphoria.org/forum/m/119312.wc
Great reason for me to not share the code with boater. Which i was considering doing.
boater appears to be able to accept that. http://openeuphoria.org/forum/m/119334.wc
30. Re: Tasks - communication
- Posted by EUWX Oct 21, 2012
- 1687 views
1. I am presuming you all are thinking of ditching Watcom, perhaps to be replace by MinGw/GCC.
Not sure what that has to do with this thread.
I am sure Euphoria is able to do 1 + 1 = 2 OR
desirable_compiler = (need_for_Tasks_communication & using_D) - watcom_compiler
I am presuming that you understand that it is axiomatic to replace Watcom with another C compiler
No. Why is this the case?
Considering that the subject of ditching Watcom has been bandied about for a year, and already some effort has been put, into MinGW as compiler;
considering that a whole thread has been started to vote for ditching Watcom;
considering that you yourself seconded the idea of "D Programming Language's approach" being very good
One cannot escape the logical conclusion that "D Programming Language" would be the correct direction to take.
Sometimes it pays to apply computer logic to day-to-day decision making.
So the only unsolved questions about which we remain in disagreement
1. Voting for ditching Watcom is not ended;
2. You think "D Programming Language" is vastly different from C, and I don't.
I am also aware of your statement regarding your liking the "D Programming Language's approach" towards "Tasks - communication" which I am sure is the title of this thread.
You presume incorrectly. I am not a fan of the D programming language, nor do I particularly like it. If my personal preference was the only factor involved, D would never be part of Eu.
I never made that statement.
You are technically right in saying "I never made that statement."
However, you seconded DerekParnell's statment which reads - see 8. Re: Tasks - communication
"I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise." You seconded this statement. My understanding of the action of a seconder is that he does not repaet the words of a motion, but his seconding of the motion implies that he FULLY AGREES with the motion.
Much as you would like to confuse between "D Programming Language's approach" and "D Programming Language", I am quite comfortable that "approach" has become tantamount to adopting the language IF the difference (as I believe) is not big, and IF YOU ARE ditching Watcom for another compiler.
So as I see it, you are wrong in believing that
1. this thread is not pointing to my conclusion;
2. A separate thread is required.
Once a decision has been made to ditch Watcom, YOU could start a thread to decide which of the several compilers are suitable, and at that time I hope you will remember the motion you seconded in this thread.
You are an admin or mod here, I am simple programmer with only 30 years experience.
Forked into: D and euphoria
31. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1880 views
<stuff>
Fine, i'll not release it, you can go fornicate.
useless
32. Re: Tasks - communication
- Posted by jaygade Oct 21, 2012
- 1694 views
<stuff>
Fine, i'll not release it, you can go fornicate.
useless
Wow. Talk about going from passive aggressive to outright aggressive.
33. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1667 views
<stuff>
Fine, i'll not release it, you can go fornicate.
useless
Wow. Talk about going from passive aggressive to outright aggressive.
You may have noticed it always happens this way when i say something and jimcbrown wants to beat me over the head with it, throwing urls, repeating thngs, allowing no leeway, allowing no change of mind or exceptions.
I was looking for a way to contact boater to send him/her the code. I didn't particularly want to share it with jimcbrown, and i certainly do not now. In fact, after jimcbrown's most recent posts, i don't particularly want to share it at all, so he sealed that deal up tightly. We are back to the devs coding up something and releasing it without me. Maybe in another 2 years?
useless
34. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1667 views
I am sure Euphoria is able to do 1 + 1 = 2 OR
desirable_compiler = (need_for_Tasks_communication & using_D) - watcom_compiler
Not sure what you're getting at here.
considering that you yourself seconded the idea of "D Programming Language's approach" being very good
You are technically right in saying "I never made that statement."
However, you seconded DerekParnell's statment which reads - see 8. Re: Tasks - communication
"I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise." You seconded this statement. My understanding of the action of a seconder is that he does not repaet the words of a motion, but his seconding of the motion implies that he FULLY AGREES with the motion.
Here is what I meant to second:
all data is assumed to be shared between tasks unless explicitly said otherwise.
Seconded.
I misread what Derek wrote, however. If D's approach is that all data is assumed to be shared between tasks unless explicitly said otherwise, then I am against it.
I like the approach where all data is assumed to not be shared between tasks unless explicitly stated to be the case, and don't care at all for D's.
This being the case, I withdraw my rhetorical motion to second.
Considering that the subject of ditching Watcom has been bandied about for a year, and already some effort has been put, into MinGW as compiler;
considering that a whole thread has been started to vote for ditching Watcom;
One cannot escape the logical conclusion that "D Programming Language" would be the correct direction to take.
Sometimes it pays to apply computer logic to day-to-day decision making.
Without my agreement to D (which I have never given), the conclusion doesn't follow logically.
So the only unsolved questions about which we remain in disagreement
1. Voting for ditching Watcom is not ended;
2. You think "D Programming Language" is vastly different from C, and I don't.
I don't see why ditching Watcom is a necessary condition for adopting D per se - but I agree that the timing would be useful.
As for point 2, I might be willing to concede it. I actually don't know much at all about D. Derek seems to be our resident D expert, so I look forward to seeing his views on this.
Much as you would like to confuse between "D Programming Language's approach" and "D Programming Language", I am quite comfortable that "approach" has become tantamount to adopting the language IF the difference (as I believe) is not big, and IF YOU ARE ditching Watcom for another compiler.
I see a huge difference between doing something similarly to D and integrating D into the language.
Our if statements are like BASIC but we can't translate code to BASIC.
Once a decision has been made to ditch Watcom, YOU could start a thread to decide which of the several compilers are suitable, and at that time I hope you will remember the motion you seconded in this thread.
I have no intention of doing this. I'm happy enough with Mingw/GCC.
So as I see it, you are wrong in believing that
1. this thread is not pointing to my conclusion;
2. A separate thread is required.
You are an admin or mod here, I am simple programmer with only 30 years experience.
I think my comments above address my POV and show why I think point 1 is true.
As for point 2, technically a separate thread is not required. But I think it'd be better for clarity to make a separate thread and keep the posts about the merits and cons of D separate from this one. Still, since the volume of posts about D to this thread is fairly low, it's really your choice whether or not you want to do this.
35. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1651 views
I am sure Euphoria is able to do 1 + 1 = 2 OR
desirable_compiler = (need_for_Tasks_communication & using_D) - watcom_compiler
Not sure what you're getting at here.
considering that you yourself seconded the idea of "D Programming Language's approach" being very good
You are technically right in saying "I never made that statement."
However, you seconded DerekParnell's statment which reads - see 8. Re: Tasks - communication
"I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise." You seconded this statement. My understanding of the action of a seconder is that he does not repaet the words of a motion, but his seconding of the motion implies that he FULLY AGREES with the motion.
Here is what I meant to second:
all data is assumed to be shared between tasks unless explicitly said otherwise.
Seconded.
I misread what Derek wrote, however. If D's approach is that all data is assumed to be shared between tasks unless explicitly said otherwise, then I am against it.
I like the approach where all data is assumed to not be shared between tasks unless explicitly stated to be the case, and don't care at all for D's.
This being the case, I withdraw my rhetorical motion to second.
You can't do that, just like i cannot send taskmsgs.e to boatie or Derek.
useless
36. Re: Tasks - communication
- Posted by EUWX Oct 21, 2012
- 1652 views
Mr Jim Brown:
I have programmed for 30 years. I have come accross countless statements as exemplified by Euphoria
Euphoria is a powerful but easy-to-learn programming language. It has a simple syntax and structure with consistent rules, and is also easy to read.
I had machine language, then assembler thrown at me and I adapted. I had GWBasic followed by QBasic folllowed by VisualBasic and about 50 variants of BASIC.
I had many more showed down my throat as "similar to BASIC" - that applies to Euphoria too.
JAVA and HTML were thrown at me as "easy languages"
I had dBase III thropwn at me followed by Clipper and FoxPro, and MS Access and SQL - all "simple database tools" and I accepted and programmed.
I did NOT shudder. I accepted and programmed in those as best as I could
Today I am seeing and experienced C language programmer who has the co-operation of half a dozen experts in C refusing to even bother about D language or to look at it.
I gives me a very clear idea of your abilities and inclinations.
37. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1644 views
I had machine language, then assembler thrown at me and I adapted. I had GWBasic followed by QBasic folllowed by VisualBasic and about 50 variants of BASIC.
I had many more showed down my throat as "similar to BASIC" - that applies to Euphoria too.
JAVA and HTML were thrown at me as "easy languages"
I had dBase III thropwn at me followed by Clipper and FoxPro, and MS Access and SQL - all "simple database tools" and I accepted and programmed.
I did NOT shudder. I accepted and programmed in those as best as I could
I have experienced and become skilled in using most of those tools as well. You do not have a monopoly here.
Today I am seeing and experienced C language programmer who has the co-operation of half a dozen experts in C refusing to even bother about D language or to look at it.
I'm not unwilling to look at it, but I feel my time is better spent waiting for the opinion of our resident D expert (who probably has already invested in a D setup) before I take time out of my busy schedule to do that.
Additionally, I feel that the right person to perform the task that you are suggesting should be a person who is already involved in and proficient with D and really enjoys using it.
I gives me a very clear idea of your abilities and inclinations.
Of course, if all D supporters and language users are like this, then I'd be perfectly happy to chuck the D language and its users out the window. Naturally, however, I already know one who is not like this at all.
38. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1631 views
You can't do that, just like i cannot send taskmsgs.e to boatie or Derek.
I'll make you a one-time deal. I'll trade you the withdrawal for a commentary-free transfer of code to boatie and/or Derek.
39. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1633 views
You can't do that, just like i cannot send taskmsgs.e to boatie or Derek.
I'll make you a one-time deal. I'll trade you the withdrawal for a commentary-free transfer of code to boatie and/or Derek.
You are too late, i made the offer to Derek, and don't know boatie's email address (and he isn't in #euphoria). So no deal.
PS: i been programming on my own computers since 1980, 32 years ago, and i had my paws, and soldering irons, in Apples before that, and ecl state machines. I did some interesting things that i was told were not possible. I didn't get useless till i tried to join with humans in programming.
useless
40. Re: Tasks - communication
- Posted by jaygade Oct 21, 2012
- 1630 views
As usual -- all talk and no code.
Let the code stand on its own merits regardless of any drama or politics.
41. Re: Tasks - communication
- Posted by EUWX Oct 21, 2012
- 1646 views
I'm not unwilling to look at it, but I feel my time is better spent waiting for the opinion of our resident D expert (who probably has already invested in a D setup) before I take time out of my busy schedule to do that.
Additionally, I feel that the right person to perform the task that you are suggesting should be a person who is already involved in and proficient with D and really enjoys using it.
A good scientist never rejects a theory because he does not like it.
Euphoria is supposed to be a team effort, so it behoves on all team members to look at alternative compilers and come to a joint decision - not a decision based on one expert.
42. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1650 views
As usual -- all talk and no code.
Let the code stand on its own merits regardless of any drama or politics.
I am not releasing the code to you or jim. You wanna play "bash the useless", go at it, it's not like you're doing anything new.
useless
43. Re: Tasks - communication
- Posted by jaygade Oct 21, 2012
- 1635 views
That's okay. You can't release it because you don't have it.
I understand.
44. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1627 views
I'm not unwilling to look at it, but I feel my time is better spent waiting for the opinion of our resident D expert (who probably has already invested in a D setup) before I take time out of my busy schedule to do that.
Additionally, I feel that the right person to perform the task that you are suggesting should be a person who is already involved in and proficient with D and really enjoys using it.
A good scientist never rejects a theory because he does not like it.
Euphoria is supposed to be a team effort, so it behoves on all team members to look at alternative compilers and come to a joint decision - not a decision based on one expert.
Agreed. If one of the devs takes up this task, or someone presents the community with a working and functional prototype, this will happen.
Alternatively, if someone wants this bad enough and is willing to pay me the right price, I'll be very happy to look into this matter myself and get a working proposal to the dev team.
Otherwise, this is a team of volunteers who donate their time to the project.
45. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1614 views
You are too late, i made the offer to Derek, and don't know boatie's email address (and he isn't in #euphoria). So no deal.
In that case, I withdraw both the second and the deal.
46. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1622 views
Let the code stand on its own merits regardless of any drama or politics.
Seconded.
47. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1641 views
That's okay. You can't release it because you don't have it.
I understand.
That's BS. But you can't provoke me into proving it exists.
EDIT:
but you could look here:
http://openeuphoria.org/forum/m/109101.wc
useless
48. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1619 views
I am not releasing the code to <snip> jim.
I haven't asked you to. I'm not interested in it. There's no need to repeat yourself here.
You wanna play "bash the eukat", go at it, it's not like you're doing anything new.
I have no interest in this either.
49. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1625 views
I am not releasing the code to <snip> jim.
I haven't asked you to. I'm not interested in it. There's no need to repeat yourself here.
You wanna play "bash the eukat", go at it, it's not like you're doing anything new.
I have no interest in this either.
I wasn't replying to your post.
useless
50. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1629 views
That's okay. You can't release it because you don't have it.
I understand.
That's BS. But you can't provoke me into proving it exists.
Considering how much of it was deleted, apparently unreleased, well, the deleted parts certainly don't exist anymore.
but you could look here:
http://openeuphoria.org/forum/m/109101.wc
Or http://openeuphoria.org/forum/m/118918.wc - but again, the unreleased stuff doesn't count.
51. Re: Tasks - communication
- Posted by jaygade Oct 21, 2012
- 1620 views
That's okay. You can't release it because you don't have it.
I understand.
That's BS. But you can't provoke me into proving it exists.
EDIT:
but you could look here:
http://openeuphoria.org/forum/m/109101.wc
useless
Ah, yes. I remember that now.
52. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1624 views
That's okay. You can't release it because you don't have it.
I understand.
That's BS. But you can't provoke me into proving it exists.
Considering how much of it was deleted, apparently unreleased, well, the deleted parts certainly don't exist anymore.
but you could look here:
http://openeuphoria.org/forum/m/109101.wc
Or http://openeuphoria.org/forum/m/118918.wc - but again, the unreleased stuff doesn't count.
Are you saying that the upgrades for unreleased code is what i was talking about in
but you could look here:
http://openeuphoria.org/forum/m/109101.wc
useless
53. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1701 views
Or http://openeuphoria.org/forum/m/118918.wc - but again, the unreleased stuff doesn't count.
Are you saying that the upgrades for unreleased code is what i was talking about in
but you could look here: http://openeuphoria.org/forum/m/109101.wc
Of course not. Merely that the (not-deleted) upgrades were part of what you were considering to offer boater.
54. Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1618 views
Or http://openeuphoria.org/forum/m/118918.wc - but again, the unreleased stuff doesn't count.
Are you saying that the upgrades for unreleased code is what i was talking about in
but you could look here: http://openeuphoria.org/forum/m/109101.wc
Of course not. Merely that the (not-deleted) upgrades were part of what you were considering to offer boater.
The released stuff which was uploaded to the internet was indeed what i was offering, you idiot. What i don't have any more is the stuff for tasks on other computers on the lan. And since i was writing the taskmsgs.e for a tasks.e version that doesn't exist, and a previous version of Euphoria, i wasn't guaranteeing it would run today. You eeuyglic idiot.
useless
55. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1617 views
You may have noticed it always happens this way when i say something and jimcbrown wants to beat me over the head with it, throwing urls, repeating thngs, allowing no leeway, allowing no change of mind or exceptions.
I admit that I have a tick. If I see something that I feel is not 100% accurate, then I feel the need to explain my POV. And I generally like to back up my views when I can.
I'm open to having my views changed (e.g. Derek convinced me that it's better to have unsigned numbers as default over signed numbers, and that we're better off using numbers rather than acronyms for the internationalization of messages), but that only follows after a long and involved discussion on the merits.
There are times when I agree to disagree (e.g. Derek and I disagreeing that unsigned numbers are inherently more natural than signed ones), but again that only follows after a long and involved discussion.
I feel that I hold back quite a bit though. I generally don't swear at people, for example.
I didn't particularly want to share it with jimcbrown, and i certainly do not now.
I'll respect your wishes on that.
I was looking for a way to contact boater to send him/her the code. In fact, after jimcbrown's most recent posts, i don't particularly want to share it at all, so he sealed that deal up tightly.
If you want to send the code to boater, that's fine with me. If you don't want to, that's fine with me. It's your code, after all. I don't really think anything I say or do should affect your decision, but, again, that's really up to you. Either way, I'm hardly responsible for your decisions.
We are back to the devs coding up something and releasing it without me. Maybe in another 2 years?
I suspect it could take even longer. Mainly because with all these comments about history, the original idea has once again fallen by the wayside.
56. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1630 views
The released stuff which was uploaded to the internet was indeed what i was offering, you idiot.
What i don't have any more is the stuff for tasks on other computers on the lan.
My mistake.
And since i was writing the taskmsgs.e for a tasks.e version that doesn't exist, and a previous version of Euphoria, i wasn't guaranteeing it would run today.
Again, my mistake. I guess the good news then is that the released code is out there and boater can find a copy of it if they need it or want it.
You eeuyglic idiot.
I approve this message!
57. Re: Tasks - communication
- Posted by ne1uno Oct 21, 2012
- 1615 views
I'm not unwilling to look at it, but I feel my time is better spent waiting for the opinion of our resident D expert (who probably has already invested in a D setup) before I take time out of my busy schedule to do that.
Additionally, I feel that the right person to perform the task that you are suggesting should be a person who is already involved in and proficient with D and really enjoys using it.
A good scientist never rejects a theory because he does not like it.
Euphoria is supposed to be a team effort, so it behoves on all team members to look at alternative compilers and come to a joint decision - not a decision based on one expert.
minGW gcc has worked since before 4.0 was released for building euphoria itself and translating euphoria programs.
dropping openwatcom won't require additional dev time finding a replacement. one of the major reasons is to "save" time testing on two compilers. any feature request to add 'D' output would have to suggest some speed or development benefit to get anyone interested who is not already using D or any other language I would guess. otherwise, why not haskel output or ocamal, proven speed demons.
58. Re: Tasks - communication
- Posted by boater Oct 22, 2012
- 1607 views
I guess the good news then is that the released code is out there and boater can find a copy of it if they need it or want it.
That *is* good news - I've found the bits of code quoted here and above - just what I was looking for in the first place. If, as it seems, I have stirred up a hornet's nest of bitterness here, my apologies - I'm just a newbie to the forum (and Eu, really) trying to make a bit of progress.
59. Re: Tasks - communication
- Posted by DerekParnell (admin) Oct 22, 2012
- 1600 views
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
I was wrong. That view in D has been replaced by a much more complex but satisfying approach. For details, have a look at ... http://www.informit.com/articles/article.aspx?p=1609144
And when I say "approach" I am not advocating the replacement of C with D. That subject deserves a whole different discussion thread. What I am referring to is the concurrency concepts implement by D should be considered for future editions of Euphoria, regardless of which system language is used by the Euphoria run-time sub-system.
60. Re: Tasks - communication
- Posted by EUWX Oct 22, 2012
- 1683 views
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
I was wrong. That view in D has been replaced by a much more complex but satisfying approach. For details, have a look at ... http://www.informit.com/articles/article.aspx?p=1609144
And when I say "approach" I am not advocating the replacement of C with D. That subject deserves a whole different discussion thread. What I am referring to is the concurrency concepts implement by D should be considered for future editions of Euphoria, regardless of which system language is used by the Euphoria run-time sub-system.
For the next two years, the logical approach to Tasks - communication is to use shared memory, not shared objects, i.e. all objects residing in shared memory space are available to all processes. Since we are talking essentially of a single user desktop, there would be no particular need for high security - just a simple approach to use of that memory would suffice.
For the next two years, the logical approach to multi - tasking is to take advantage of multi-core processors.
For Euphoria, based on a quad core processor, multi - tasking and Tasks - communication is a feasible and desirable objective for eight simultaneous processes, without the system grinding to a halt.
I am neither a C, nor a D programmer. However, I feel that anybody who can take a quantum jump from GW BASIC to Visual BASIC, from dBase to SQL and Hadoop, should be able to take the earthworm's jump from C to D, particularly if he is adapt in one or the other.
Beyond that, I would suggest you look at Euphoria on the Desktop computer's video processor using CUDA
http://www.nvidia.com/object/cuda_home_new.html and/or
64 CPU Raspberry PI SuperComputer.
http://www.southampton.ac.uk/~sjc/raspberrypi/
For those who live in the vicinity of Toronto, these topics are being discussed in the annual
Free Software and Open Source Symposium 2012 (25-26 October, 2012) at Seneca College. http://fsoss.senecac.on.ca/2012/
It seems the registration is closed, but I suppose one can try at the door.
I do agree that these approaches require separate discussion threads and building dedicated teams. However, nothing can be achieved nor archived by presuming any poster to be a novice when he makes a simple typo. I have treated everybody here as serious programmers, whose typos and apparent lack of understanding is to be overlooked or explained to them.
61. Re: Tasks - communication
- Posted by gharris Oct 22, 2012
- 1573 views
Its been a long time since I did a lot of programming in Euphoria so I won't post any code here yet. Since tasks in Euphoria are not technically considered threaded, it should be fairly easy to make a interprocess messaging system for it.
One way to do this is using global FIFO stacks to store the shared data. A producer task puts data into the stack so worker tasks can pull the data to process it.
A more robust system can use maps to store messages sent by other tasks then retrieved when needed. I wrote a simple system like this in Python years ago.
A simple way to share data between other external processes could be the use of external systems such as Redis.
Hope this helps.
62. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 22, 2012
- 1525 views
For the next two years, the logical approach to Tasks - communication is to use shared memory, not shared objects, i.e. all objects residing in shared memory space are available to all processes.
I like this idea. Shared memory IPC.
Since we are talking essentially of a single user desktop, there would be no particular need for high security - just a simple approach to use of that memory would suffice.
Sane OSes have builtin security measures for shared memory anyways, if you do need them.
For the next two years, the logical approach to multi - tasking is to take advantage of multi-core processors.
Agreed. What's with the "next two years" though?
For Euphoria, based on a quad core processor, multi - tasking and Tasks - communication is a feasible and desirable objective for eight simultaneous processes, without the system grinding to a halt.
So two Eu processes running per core on a quad core? Since you mean processes - we can do this already.
I am neither a C, nor a D programmer. However, I feel that anybody who can take a quantum jump from GW BASIC to Visual BASIC, from dBase to SQL and Hadoop, should be able to take the earthworm's jump from C to D, particularly if he is adapt in one or the other.
I look forward to seeing you make that jump and seeing what you come up with.
Beyond that, I would suggest you look at <snip> For those who live in the vicinity of Toronto <snip>
Something seems off here. It's like reading a horror story and then abruptly switching into a comedy routine. The segway is nonexistent and it's hard to see why you bring it up.
I do agree that these approaches require separate discussion threads and building dedicated teams.
Glad we can agree on that.
However, nothing can be archived by presuming any poster to be a novice when he makes a simple typo. I have treated everybody here as serious programmers, whose typos and apparent lack of understanding is to be overlooked or explained to them.
Here you made the same typo twice: archived instead of achieved. Or more likely, you copy and pasted when making the second post to the other thread.
However, I agree with your point. A coder's abilities should be judged by that person's code and troubleshooting skills, not by that coder's skill in a given spoken language. Likewise, a forum poster should be judged on other things, like clarity of communication and conflict resolution ability.
Still, you have to admit, making a typo of MB for GB, and then denying it when it was pointed out to you TWICE, was a pretty serious gaffe. I'm not saying that this means you are a novice to programming, just that you are someone who once made a gaffe.
63. Re: Tasks - communication
- Posted by EUWX Oct 22, 2012
- 1544 views
I am a much better English language user than you are. Look at my current version of what you called a typo.
64. Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 22, 2012
- 1682 views
I am a much better English language user than you are. Look at my current version of what you called a typo.
Ok, you wrote:
However, nothing can be achieved nor archived by presuming any poster to be a novice when he makes a simple typo.
Clearly that's grammatically correct. But you're wrong - I can presume that you're a novice and archive the whole thing. (Obviously, stating that "nothing can be archived if .." makes no sense given the context.)
This inability of yours to admit to making mistakes is a more serious issue to me. In light of this, I'm now considering whether or not you are a good addition to the forum.
I have treated everybody here as serious programmers, whose typos and apparent lack of understanding is to be overlooked or explained to them.
Your latest post to me means that you have done otherwise.
65. Re: Tasks - communication
- Posted by DerekParnell (admin) Oct 22, 2012
- 1575 views
I am sure Euphoria is able to do 1 + 1 = 2 OR
desirable_compiler = (need_for_Tasks_communication & using_D) - watcom_compiler
I don't think I understand what you meant by that, sorry.
Are you saying that the desirable compiler would be one that satisfies the need for task communication and uses the D programming Language and does not use Watcom complier?
I am presuming that you understand that it is axiomatic to replace Watcom with another C compiler
No. Why is this the case?
I'm not sure why you are using 'axiomatic'.
Considering that the subject of ditching Watcom has been bandied about for a year, and already some effort has been put, into MinGW as compiler;
considering that a whole thread has been started to vote for ditching Watcom;
considering that you yourself seconded the idea of "D Programming Language's approach" being very good
One cannot escape the logical conclusion that "D Programming Language" would be the correct direction to take.
Sometimes it pays to apply computer logic to day-to-day decision making.
It may be that you misunderstood my comment about D. I was not saying that the D Programming Language should be used, but that we should look into the D's conceptual treatment of task/process communication and see if we can get any benefit of implementing that concept into Euphoria - regardless of which compiler/language we code Euphoria's run-time system with.
So the only unsolved questions about which we remain in disagreement
1. Voting for ditching Watcom is not ended;
2. You think "D Programming Language" is vastly different from C, and I don't.
Voting for Watcom removal has not ended yet. There are still opinions that we need to hear from and consider.
From practical experience, I would argue that "D Programming Language" and "C Programming Language" are very different from each other, in spite of the common syntax look-and-feel. The underlying paradigms and constructs are not compatible. A good C programmer would tend to write poor D code if they failed to think in D, and visa versa.
However, you seconded DerekParnell's statment which reads - see 8. Re: Tasks - communication
"I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise." ...
Much as you would like to confuse between "D Programming Language's approach" and "D Programming Language", I am quite comfortable that "approach" has become tantamount to adopting the language IF the difference (as I believe) is not big, and IF YOU ARE ditching Watcom for another compiler.
I'm sorry if I didn't make myself clear about D. Liking D's approach to inter task communications is in no way meant as an endorsement for adopting the D language as Euphoria's system language.
You are an admin or mod here, I am simple programmer with only 30 years experience.
And by the way, I started my programming experience in 1972, not that that has any relevance to anything except to my age.
