Linking with LLVM on Windows
I'm trying to link with a recent build of LLVM on windows. I built LLVM 3.1 as a DLL using mingw, converted DLL to LIB with implib, however the link fails with the error C:\cal\D\dmd2\windows\bin\..\lib\snn.lib(printf) Offset FFAB9H Record Type 00C3 Error 1: Previous Definition Different : _fprintf Has anyone tried linking with LLVM under Windows? I can't seem to find where LLVM redefines or pulls-in fprintf, although I can see where it is in the LIB. Appreciate any suggestions.
Re: How to have strongly typed numerical values?
On 05/09/12 03:42, bearophile wrote: Nicholas Londey: for example degrees west and kilograms such that they cannot be accidentally mixed in an expression. Using the static typing to avoid similar bugs is the smart thing to do :-) I'd be interested to know if that idea is ever used in real code. I mean, it's a classic trendy template toy, but does anyone actually use it? I say this because I've done a lot of physics calculation involving multiple complicated units, but never seen a use for this sort of thing. In my experience, problems involving units are easily detectable (two test cases will catch them all). The most insidious bugs are things like when you have used constants at 25'C instead of 20'C, or when you have a sign wrong.
Re: How to have strongly typed numerical values?
Don Clugston: I'd be interested to know if that idea is ever used in real code. I mean, it's a classic trendy template toy, but does anyone actually use it? As usual I don't have usage statistics. I like dynamic languages, like Python. But if you give me a static type system, then I want something back from the language. Detecting certain bugs at compile-time is one way to pay me back. If you want most programmers to use a feature like units, it needs: - Built-in, in the standard library, or easy to install; - To have a compact and very nice looking syntax; - Easy enough to use; - Flexible, to be able to represent all units you find in many real problems; - Have zero or near-zero run-time costs, in both CPU and memory; - Give acceptable error messages. I think in F# people are using units often enough. If a units system will be present in Phobos and it will be very good to use, maybe D programmers will use them. I am currently using Haskell a little, and I am enjoying giving types to values to tell them apart in terms of their usage. I say this because I've done a lot of physics calculation involving multiple complicated units, but never seen a use for this sort of thing. In my experience, problems involving units are easily detectable (two test cases will catch them all). The most insidious bugs are things like when you have used constants at 25'C instead of 20'C, or when you have a sign wrong. There are some famous problems caused by mixing units: http://lamar.colostate.edu/~hillger/unit-mixups.html Maybe this is the most famous: http://mars.jpl.nasa.gov/msp98/news/mco990930.html Bye, bearophile
DMD flags
In C/C++, with f.c or f.cpp I can do: cc f.o -lncurses something similar works for gdc, but what to write for dmd? Assuming f.d obviously :-) Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: DMD flags
On 2012-09-05 13:59, Russel Winder wrote: In C/C++, with f.c or f.cpp I can do: cc f.o -lncurses something similar works for gdc, but what to write for dmd? Assuming f.d obviously :-) Thanks. GDC/GCC just forwards that flag to the linker, so: dmd f.d -L-lncurses -- /Jacob Carlborg
Re: DMD flags
On Wed, 2012-09-05 at 14:04 +0200, Jacob Carlborg wrote: […] GDC/GCC just forwards that flag to the linker, so: dmd f.d -L-lncurses Hummm… I had thought of that but rejected it due to the word flag being drawn more towards GCC -L than -l. Anyway, used and working. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
RTP/RTCP in D?
Hi all, is there a convenient way (bindings?) to use RTP/RTCP protocols from within a D project? I'm developing a client/server application where only tiny bursts of data (i.e. messages) have to be exchanged between srv and clt, and TCP sockets don't do the trick ;_; Or is there a better, but whole different approach to this than the RTP protocol family? Thx 4 answering!
Re: modulename
On 2012-09-04 15:36, Andrej Mitrovic wrote:
9/4/12, Ellery Newcomerellery-newco...@utulsa.edu wrote:
On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:
__FILE__?
It doesn't necessarily have the exact package hierarchy.
We could really use __MODULE__ then. I think it's been asked before
but I didn't see any enhancement request in buzilla.
+1 would love this too
so far tried to get away with __FILE__ but this has issues, as noted before.
on a slightly different note, __FILE__ and __LINE__ are not quite doing what
they are supposed to do either:
http://dlang.org/template.html
Template Value Parameters
The __FILE__ and __LINE__ expand to the source file name and line number at the
point of instantiation.
unfortunately, they only do this for functions (sort of¹), not for other
templates. dunno why, i think it is just not implemented. in fear of code
bloat? i don't get this argument though. if you use __FILE__ and such
extensively it would be only in debugging scenarios. other than that, you
shouldn't have many of those. at least this is the case in my code. and the
danger of code bloat with templates is omnipresent, no reason to single out
__FILE__ usage.
¹using funtempl(Ps)(As){...}:
+ always works in argument list (As), also in non-templated functions
+ as template parameter (P), works only when called short: funtempl()
- as template parameter(P), this does not work: funtempl!()()
Re: modulename
On Sep 5, 2012, at 10:56, captaindet 2k...@gmx.net wrote: On 2012-09-04 15:36, Andrej Mitrovic wrote: 9/4/12, Ellery Newcomerellery-newco...@utulsa.edu wrote: On 09/04/2012 12:41 PM, Andrej Mitrovic wrote: __FILE__? It doesn't necessarily have the exact package hierarchy. We could really use __MODULE__ then. I think it's been asked before but I didn't see any enhancement request in buzilla. +1 would love this too so far tried to get away with __FILE__ but this has issues, as noted before. on a slightly different note, __FILE__ and __LINE__ are not quite doing what they are supposed to do either: http://dlang.org/template.html Template Value Parameters The __FILE__ and __LINE__ expand to the source file name and line number at the point of instantiation. unfortunately, they only do this for functions (sort of¹), not for o ther templates. It should work for templates too; std.log uses this extensively. Or at least it used to work. Can you post the code sample where it doesn't work?
bigint - python long
Hey. Investigating the possibility of providing this conversion in pyd. Python provides an api for accessing the underlying bytes. std.bigint seemingly doesn't. Am I missing anything?
Re: modulename
On Wednesday, September 05, 2012 11:05:10 Jose Armando Garcia wrote: It should work for templates too; std.log uses this extensively. Or at least it used to work. Can you post the code sample where it doesn't work? Regardless of whether it works, __FILE__ and __LINE__ should be used as template arguments with extreme caution, because you end up with a new instantiation for _every_ use (at least if you use both together). If it's broken, it should certainly be fixed, but it's not a feature to be used lightly. - Jonathan M Davis
Re: modulename
On 9/5/12, Jonathan M Davis jmdavisp...@gmx.com wrote:
Regardless of whether it works, __FILE__ and __LINE__ should be used as
template arguments with extreme caution, because you end up with a new
instantiation for _every_ use (at least if you use both together).
Honestly it would be much better if the file and line were symbols you
could retrieve at any point in your function, e.g.:
void foo()
{
string file = __FILE__; // file of inside
int line = __LINE__; // line inside foo
string callFile = __INFILE__; // file of invocation
int line = __INLINE__; // line of invocation
}
That way you don't have to mess with your CT/RT parameters if all you
want to do is printf-style debugging.
Re: modulename
On Wednesday, September 05, 2012 20:46:08 Andrej Mitrovic wrote:
On 9/5/12, Jonathan M Davis jmdavisp...@gmx.com wrote:
Regardless of whether it works, __FILE__ and __LINE__ should be used as
template arguments with extreme caution, because you end up with a new
instantiation for _every_ use (at least if you use both together).
Honestly it would be much better if the file and line were symbols you
could retrieve at any point in your function, e.g.:
void foo()
{
string file = __FILE__; // file of inside
int line = __LINE__; // line inside foo
string callFile = __INFILE__; // file of invocation
int line = __INLINE__; // line of invocation
}
That way you don't have to mess with your CT/RT parameters if all you
want to do is printf-style debugging.
That would be _way_ harder to implement. As it is, it's trivial to insert the
__FILE__ and __LINE__ as default arguments at the call site. Doing __INFILE__
or __INLINE__ would require providing additional, invisible arguments to the
function for the __FILE__ and __LINE__ at the call site, and it would
invisibly change the function's signature depending on whether __INFILE__
and/or __INLINE__ were used in the function or not. I'd be very surprised if
that sort of thing were considered acceptable by the compiler devs.
With how C linkage is designed, it doesn't care about the call site at all. A
function has no idea where it's called from and doesn't care. The only reason
that we got __FILE__ and __LINE__ to work like they do with default arguments
is because it was trivial to change it so that they used the values at the
call site rather than the declaration site, because those values are copy-
pasted at the call site anyway. Anything which would require the function
itself actually having access to the scope that it was called from would
complicate things considerably.
- Jonathan M Davis
Re: bigint - python long
On Wednesday, 5 September 2012 at 18:13:40 UTC, Ellery Newcomer wrote: Hey. Investigating the possibility of providing this conversion in pyd. Python provides an api for accessing the underlying bytes. std.bigint seemingly doesn't. Am I missing anything? No, I don't believe so. AFAIK there is no public access to the underlying array, but I think it is a good idea. I suspect the reason for not disclosing the details is to disallow anyone putting the data into an invalid state. But read-only access would be safe.
Re: modulename
On 9/5/12, Jonathan M Davis jmdavisp...@gmx.com wrote: That would be _way_ harder to implement. Right, this would only work for templated functions, but maybe not worth adding then.
Re: How to have strongly typed numerical values?
On Wednesday, 5 September 2012 at 11:50:12 UTC, bearophile wrote: Don Clugston: I'd be interested to know if that idea is ever used in real code. I mean, it's a classic trendy template toy, but does anyone actually use it? As usual I don't have usage statistics. I like dynamic languages, like Python. But if you give me a static type system, then I want something back from the language. Detecting certain bugs at compile-time is one way to pay me back. If you want most programmers to use a feature like units, it needs: - Built-in, in the standard library, or easy to install; - To have a compact and very nice looking syntax; - Easy enough to use; - Flexible, to be able to represent all units you find in many real problems; - Have zero or near-zero run-time costs, in both CPU and memory; - Give acceptable error messages. I think in F# people are using units often enough. If a units system will be present in Phobos and it will be very good to use, maybe D programmers will use them. I am currently using Haskell a little, and I am enjoying giving types to values to tell them apart in terms of their usage. I say this because I've done a lot of physics calculation involving multiple complicated units, but never seen a use for this sort of thing. In my experience, problems involving units are easily detectable (two test cases will catch them all). The most insidious bugs are things like when you have used constants at 25'C instead of 20'C, or when you have a sign wrong. There are some famous problems caused by mixing units: http://lamar.colostate.edu/~hillger/unit-mixups.html Maybe this is the most famous: http://mars.jpl.nasa.gov/msp98/news/mco990930.html Bye, bearophile FWIW, there was a proposal (JSR-275) to add support for units of measure to Java that was ultimately rejected. The implementation can be found at JScience.org, written and maintained by the website owner, Jean-Marie Dautelle, who also led the JSR team. Paul
Re: bigint - python long
On Wednesday, 5 September 2012 at 19:23:11 UTC, Paul D. Anderson wrote: No, I don't believe so. AFAIK there is no public access to the underlying array, but I think it is a good idea. I meant to say I think that access to the array is a good idea, not the lack of access. Words are hard!
Re: bigint - python long
Ellery Newcomer: Investigating the possibility of providing this conversion in pyd. Are you updating Pyd? :-) Bye, bearophile
Re: modulename
On 2012-09-05 13:05, Jose Armando Garcia wrote:
On Sep 5, 2012, at 10:56, captaindet 2k...@gmx.net wrote:
On 2012-09-04 15:36, Andrej Mitrovic wrote:
9/4/12, Ellery Newcomerellery-newco...@utulsa.edu wrote:
On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:
__FILE__?
It doesn't necessarily have the exact package hierarchy.
We could really use __MODULE__ then. I think it's been asked
before but I didn't see any enhancement request in buzilla.
+1 would love this too
so far tried to get away with __FILE__ but this has issues, as
noted before.
on a slightly different note, __FILE__ and __LINE__ are not quite
doing what they are supposed to do either:
http://dlang.org/template.html Template Value Parameters The
__FILE__ and __LINE__ expand to the source file name and line
number at the point of instantiation.
unfortunately, they only do this for functions (sort of¹), not for
other templates.
It should work for templates too; std.log uses this extensively. Or
at least it used to work. Can you post the code sample where it
doesn't work?
i had a quick look at std.log and it seems to use __LINE__ and __FILE__ only as
function argument defaults or parameter defaults for templated functions. these
are the only cases where it actually works (with the one syntax catch though).
however, it does not work for bare/mixin tamplates, templated structs or
templated classes. (so i ended up writing factory functions for my code)
here a test program:
/**
__LINE__ testing for
F := function S := struct C := class T := template
MT := mixin template
as
A := function value argumentP := template value parameter
using dmd2.060 /windows prints:
Instantiating Code starts line: 63
F(A)
OK : captured line = 67
T(P)
FAIL : captured line = 43
MT(P)
FAIL : captured line = 46
TF()(A)
OK : captured line = 78
TF(P)(): short call syntax: TF_P()
OK : captured line = 82
TF(P)(): longer call syntax: TF_P!()()
FAIL : captured line = 52
TS(P)
FAIL : captured line = 55
TC(P)
FAIL : captured line = 58
**/
module testline;
import std.stdio;
size_t F_A( size_t l = __LINE__ ){
return l; }
template T_P( size_t l = __LINE__ ){
enum size_t t_p = l; }
mixin template MT_P( size_t l = __LINE__ ){
enum size_t mt_p = l; }
size_t TF_A()( size_t l = __LINE__ ){
return l; }
size_t TF_P( size_t l = __LINE__ )(){
enum size_t _l = l; return _l; }
struct TS_P( size_t l = __LINE__ ){
size_t _l = l; }
class TC_P( size_t l = __LINE__ ){
size_t _l = l; }
void main(){
size_t L = __LINE__;// if things work: __LINE__ L
writeln(\nInstantiating Code starts line: , L);
writeln(\nF(A));
auto l_f_a = F_A();
writeln((l_f_aL)?OK:FAIL, : captured line = , l_f_a);
writeln(\nT(P));
writeln((T_P!().t_pL)?OK:FAIL, : captured line = , T_P!().t_p);
writeln(\nMT(P));
mixin MT_P!();
writeln((mt_pL)?OK:FAIL, : captured line = , mt_p);
writeln(\nTF()(A));
auto l_tf_a = TF_A!()();
writeln((l_tf_aL)?OK:FAIL, : captured line = , l_tf_a);
writeln(\nTF(P)(): short call syntax: TF_P());
auto l_tf_p = TF_P();
writeln((l_tf_pL)?OK:FAIL, : captured line = , l_tf_p);
writeln(\nTF(P)(): longer call syntax: TF_P!()());
auto l_tf_p2 = TF_P!()();
writeln((l_tf_p2L)?OK:FAIL, : captured line = , l_tf_p2);
writeln(\nTS(P));
TS_P!() ts_p;
writeln((ts_p._lL)?OK:FAIL, : captured line = , ts_p._l);
writeln(\nTC(P));
auto tc_p = new TC_P!();
writeln((tc_p._lL)?OK:FAIL, : captured line = , tc_p._l);
}
Re: bigint - python long
On 09/05/2012 05:02 PM, bearophile wrote: Ellery Newcomer: Investigating the possibility of providing this conversion in pyd. Are you updating Pyd? :-) Bye, bearophile Yep. Have any suggestions for supported conversion out of the box? From the standard library, I already have Complex, Tuple, and now BigInt. Was thinking maybe the datetime stuff.. Also, which of the following looks more appealing to you? wrap_class!(Foo, Def!(Foo.bar, PyName!__len__))(); wrap_class!(Foo, Len!(Foo.bar))(); they wrap Foo and give it an overriden __len__; the latter is how it is done at the moment (with similar templates for the other operators), but boost::python does something akin to the former. PyName is in the former because Def takes too many optional string arguments.
Re: bigint - python long
Ellery Newcomer: Yep. Oh, good. Have any suggestions for supported conversion out of the box? There are several important cases, like: Some D lazy ranges == Python lazy iterators/generators array.array == D arrays NumPy arrays == D arrays Also, which of the following looks more appealing to you? I don't know. Bye, bearophile
Re: bigint - python long
On 09/05/2012 07:10 PM, bearophile wrote:
Some D lazy ranges == Python lazy iterators/generators
I'll look into this one.
array.array == D arrays
just checked, looks like we have it:
PyStmts(q{from array import array; a = array('i', [44,33,22,11]);},
testing);
assert(PyEval!(int[])(a, testing) == [44,33,22,11]);
I think if the python object is iterable, it can be converted to array.
Matrices might pose a problem. But user can define custom conversions if
need be.
NumPy arrays == D arrays
I have never used NumPy. Are its arrays special?
Also, which of the following looks more appealing to you?
I don't know.
ok, I'll be lazy then.
