1. rev 4.0 call_back
- Posted by bernie Jan 27, 2009
- 854 views
It might be a good idea to let users know when
the call_back() has been moved to a new standard library.
The documents still show it as being in dll.e
This move causes broken windows code that was previously working.
2. Re: rev 4.0 call_back
- Posted by mattlewis (admin) Jan 27, 2009
- 810 views
It might be a good idea to let users know when
the call_back() has been moved to a new standard library.
The documents still show it as being in dll.e
This move causes broken windows code that was previously working.
Yeah, I'm not sure why it was moved it in the first place.
Matt
3. Re: rev 4.0 call_back
- Posted by jimcbrown (admin) Jan 27, 2009
- 806 views
It might be a good idea to let users know when
the call_back() has been moved to a new standard library.
The documents still show it as being in dll.e
This move causes broken windows code that was previously working.
Yeah, I'm not sure why it was moved it in the first place.
Matt
The sole reason for this was to keep the set of includes in a tree graph.
(If call_back() was in dll.e, then dll.e would need to include machine.e - which includes dll.e currently in order to handle the DEP support)
4. Re: rev 4.0 call_back
- Posted by mattlewis (admin) Jan 27, 2009
- 811 views
...call_back() has been moved to a new standard library.
Yeah, I'm not sure why it was moved it in the first place.
The sole reason for this was to keep the set of includes in a tree graph.
(If call_back() was in dll.e, then dll.e would need to include machine.e - which includes dll.e currently in order to handle the DEP support)
Is that important? Being able to ignore this was one of the main benefits of adding forward referencing. We have multiple places in the standard library that have cycles in their dependency graphs.
Matt
5. Re: rev 4.0 call_back
- Posted by jimcbrown (admin) Jan 27, 2009
- 828 views
...call_back() has been moved to a new standard library.
Yeah, I'm not sure why it was moved it in the first place.
The sole reason for this was to keep the set of includes in a tree graph.
(If call_back() was in dll.e, then dll.e would need to include machine.e - which includes dll.e currently in order to handle the DEP support)
Is that important? Being able to ignore this was one of the main benefits of adding forward referencing. We have multiple places in the standard library that have cycles in their dependency graphs.
Matt
I was being overcautious and trying to prevent machine.e/dll.e from breaking in case a bug in forward referencing was introduced later (it seems silly to have it the stdlib break just because of call_back() ) - but if we already have other circular dependencies then it isn't really important.
I would have prefered that the DEP stuff be moved into the C code, rather than including dll.e in machine.e to handle the implementation in euphoria, but this is also a fairly unimportant detail.
6. Re: rev 4.0 call_back
- Posted by mattlewis (admin) Jan 27, 2009
- 857 views
I would have prefered that the DEP stuff be moved into the C code, rather than including dll.e in machine.e to handle the implementation in euphoria, but this is also a fairly unimportant detail.
Yeah, that's what I thought we were going to do, too, but I suppose it's not really performance critical code, so it probably doesn't matter.
Matt
