Re: Delegate parameter name shadows type name
On 2017-01-09 20:51, Ali Çehreli wrote: Those two syntaxes always confuse me and I'm never sure without trying which one to use when. :) However, the code is correct in this case because that's a delegate instance. I agree. When it comes to declaring a delegate type, i.e. a variable or function parameter I always think that the syntax is the same as the declaring a regular function, but replacing the function name with "delegate". -- /Jacob Carlborg
Re: Android Status
On Monday, 9 January 2017 at 18:38:01 UTC, Ignacious wrote: On Monday, 9 January 2017 at 08:28:04 UTC, Joakim wrote: I've tried to write up detailed instructions on the wiki. I'm still improving those and plan to spin off those two sections I linked you, on how to just build the samples, into their own page. You can contribute any steps you had to take with Bash/Ubuntu on Windows with the prebuilt linux/x64 cross-compiler there, once I put the page up. Yeah, I found it a bit confusing though. It seems like it is written up by someone that is working on the core rather than a newb! ;) Yep, that's what it is. That's one reason why I want to add another wiki page which will just focus on building the sample apps, as opposed to building the cross-compiler too. The main problem I have had seems to be that UoW uses ver 14. Somehow I was able to upgrade by following docs online(wasn't easy but eventually got there and everything seems to work... I should have documented ;) but I wasn't sure if the process would work. Supposedly ver 16 exists by one has to be part of the dev team or something. If you know all the steps to upgrade Ubuntu on Windows, you may want to document them on the wiki page I will put up or link to a good resource that shows how to do it. I don't because it was all new to me(I didn't know there was even such a thing as UoW. I simply searched for the errors I got and tried different solutions until it worked. Luckily the outcome worked... which is not always the case. Is it easy for you to nuke it and go back to the original 14.04 setup? I may be able to remove some of those ldc library dependencies, so that it works on the original setup too. I think that it would be a boon for D to have some type of well defined and well planned Android development suite rather than what seems to be hacked/cobbled together. This would bring not only more developers to D for android but also to D in general. Yes, definitely the plan. The big problem right now is that it requires a slightly modified llvm. If that weren't needed, we could just have the official release builders also build the standard library for Android/ARM on their OS. I'm gonna try the opengl examples and hopefully the work. The main problem I see is how to actually write "commercial" apps using D for android. Can it be done successfully? Nobody knows because there isn't a history. What are the exact steps, say, to add ads, or interface with the subsystem? I saw that there is some way to call some java stuff from D but seems like nothing is thoroughly tested(most of the work as been just trying to get things up and running). I got interfacing with Java working late last year, through JNI. Not "thoroughly tested" by any means, but seems to work. The only way to know whether commercial Android apps can be written in D is to actually do it. I plan on writing one this year. On Monday, 9 January 2017 at 23:24:08 UTC, Ignacious wrote: How difficult is it to build for x86/x64? Would be nice to be able to use something like http://www.android-x86.org/ as a test instead of an actual device. Does one simply have to use the proper ldc2/dmd and link in the correct libs? or is it more complex? Not too hard. I haven't bothered with it because Android/x86 had almost no market share, and Intel has essentially given up and pulled out of that market. I may someday update it again, but the problem right now is that I don't have an x86 machine on which to try it. I've gone all ARM and setting Android/x86 up on a VPS takes some work. Also, I'm a bit confused on how to compile the source examples(working it out and trying to explain the solutions as I type) https://wiki.dlang.org/Build_DMD_for_Android As noted there, those instructions haven't been updated in a year and a half and are out of date. I just updated the wiki page with a stronger warning. (set $NDK permanently) I have done(easy, find the file and modify) rt_init(); android_main(android_app); rt_term(); Clean up and compile as before: $NDK/ndk-build clean NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1 But no error. Object files for various architectures are created though, it seems. (rt_ errors do no exist contrary to what is said in the docs) I'm not sure why that wouldn't error anymore, it should be the same. Anyway, since I wrote those instructions a couple years ago, I translated the google-provided android_native_app_glue.c to android_native_app_glue.d and didn't bother updating the instructions for Android/x86. But the following seems need updating/explaining. I am using prebuilt ldc2 for android from some link you provided. -android doesn't seem to work and I can't find sensor.d (not sure if it is needed anymore)? ../../../dmd/src/dmd -android -I../.. -ofobj/local/x86/objs/native-activity main.o -c jni/main.d ../../android/sensor.d I had to change to use
Re: Primality test function doesn't work on large numbers?
Thank you! Would you mind telling me what you changed aside from
pow() and powm()? diff isn't giving me readable results, since
there was some other stuff I trimmed out of the original file.
Also, while this is a *lot* better, I still get some lag
generating 1024-bit primes and I can't generate larger primes in
a reasonable amount of time. Maybe my genbigint() function is to
blame? It isn't efficient:
bigint genbigint(int numbits) {
bigint tmp;
while (numbits --> 0) {
tmp <<= 1;
tmp += uniform(0, 2);
}
return tmp;
}
Re: Getch() Problem: C vs D
On Tuesday, 10 January 2017 at 02:37:31 UTC, LouisHK wrote: Again this worked for me, but my terminal.d version is a bit older, and you may had already fixed, I can't change the version right now to test because I have some legacy code. k. I try not to break things very often btw. terminal.d does have a minor change lately but code that worked on like any version over the last i think almost two years should keep working now. If I did it right.
Re: Getch() Problem: C vs D
On Tuesday, 10 January 2017 at 02:04:07 UTC, Adam D. Ruppe wrote:
On Tuesday, 10 January 2017 at 01:06:53 UTC, LouisHK wrote:
So, I thought a little bit and I changed the terminal.d to
check on the KeyEvent if the KeyEvent.bKeyDown is true,
otherwise assigns a null event, and it's working fine and now
I can get the ESCAPE key. :)
What line did you change? ...
So, I was seeing and my version is a bit older than the one in
the GitHub, but I looked over it, and I think you should put the
code below at the line 1797[1]:
if(!buffer[0].KeyEvent.bKeyDown){ return null ;}
So, it will stay inside the case KEY_EVENT: and will check the if
KEY status is DOWN, otherwise will return null event.
Again this worked for me, but my terminal.d version is a bit
older, and you may had already fixed, I can't change the version
right now to test because I have some legacy code. But I'll try
in another computer with the last version.
[1]:
(https://github.com/adamdruppe/arsd/blob/master/terminal.d#L1797).
L.
Re: Getch() Problem: C vs D
On Monday, 9 January 2017 at 23:33:45 UTC, Era Scarecrow wrote: For direct interactions (a game menu or similar) getting individual characters makes sense; I can't help but think Rogue-likes. However for data input (per line basis) or doing bulk data/processing, it doesn't work well. Well, line processing depends on which level you're working on. My terminal.d includes a getline() function which gives the high level interface on a line level, but its implementation uses the individual events (and you can hook those for customization btw) because it allows the library to provide a much richer UX - line navigation with arrow keys, editing, insertion, etc. Bulk I/O is a major win too, but with direct user interaction, the bottleneck is (almost always nowadays) the user's actual input - even quick typists are insanely slow sources of data as far as the computer is concerned. And there, being able to arrow, backspace, etc., is a huge productivity win for them and seeing the individual events gives the program the control it needs to make that work well.
Re: Getch() Problem: C vs D
On Tuesday, 10 January 2017 at 01:06:53 UTC, LouisHK wrote: So, I thought a little bit and I changed the terminal.d to check on the KeyEvent if the KeyEvent.bKeyDown is true, otherwise assigns a null event, and it's working fine and now I can get the ESCAPE key. :) What line did you change? Maybe I can merge your change in, though I gotta make sure it doesn't break the key release events (which are supposed to be opt-in, so they should be ignored by default, but they are also supposed to be processable.)
Re: Getch() Problem: C vs D
On Monday, 9 January 2017 at 20:12:38 UTC, Adam D. Ruppe wrote: Probably a bug, though I don't like using the getch function, I usually use the full input stream. So, I thought a little bit and I changed the terminal.d to check on the KeyEvent if the KeyEvent.bKeyDown is true, otherwise assigns a null event, and it's working fine and now I can get the ESCAPE key. :) terminal.d is truly amazing, I'm doing a lot of things with it. Thanks, L.
Re: Loading assimp
On Monday, 9 January 2017 at 18:13:03 UTC, Dlearner wrote: I'm trying to use assimp to load models in a program. I see the Derelict binding is for version 3.3, but the assimp site has no binaries for this, just source. So I try to use version 3.1.1 and I get this error: derelict.util.exception.SymbolLoadException@..\..\AppData\Roaming\dub\packages\derelict-util-2.0.6\derelict-util\source\derelict\util\exception.d(35): Failed to load symbol aiReleaseExportFormatDescription from shared library assimp.dll Use version 1.1.1 of DerelictASSIMP3. It's implemented against ASSIMP 3.1.
Re: Getch() Problem: C vs D
On Monday, 9 January 2017 at 20:12:38 UTC, Adam D. Ruppe wrote: Probably a bug, though I don't like using the getch function, I usually use the full input stream. For direct interactions (a game menu or similar) getting individual characters makes sense; I can't help but think Rogue-likes. However for data input (per line basis) or doing bulk data/processing, it doesn't work well. Something to comment on, a while back when I was first getting into C and MS-DOS assembly programming, I did a direct file-copy using only one character input/write at a time. A meg sized file probably took a minute or so while if I did something as small as a 4k buffer it took moments (approx 8000x faster). This was back in 1996 or so, still it's obvious the advantages of working in bulk.
Re: Android Status
How difficult is it to build for x86/x64? Would be nice to be able to use something like http://www.android-x86.org/ as a test instead of an actual device. Does one simply have to use the proper ldc2/dmd and link in the correct libs? or is it more complex? Also, I'm a bit confused on how to compile the source examples(working it out and trying to explain the solutions as I type) https://wiki.dlang.org/Build_DMD_for_Android (set $NDK permanently) I have done(easy, find the file and modify) rt_init(); android_main(android_app); rt_term(); Clean up and compile as before: $NDK/ndk-build clean NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1 But no error. Object files for various architectures are created though, it seems. (rt_ errors do no exist contrary to what is said in the docs) But the following seems need updating/explaining. I am using prebuilt ldc2 for android from some link you provided. -android doesn't seem to work and I can't find sensor.d (not sure if it is needed anymore)? ../../../dmd/src/dmd -android -I../.. -ofobj/local/x86/objs/native-activity main.o -c jni/main.d ../../android/sensor.d I had to change to use ldc2, remove -android, and obviously change the file names and such(and download the android dir from github). $NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang -Wl,-soname,libnative-activity.so -shared --sysroot=$NDK/platforms/android-9/arch-x86 ./obj/local/x86/objs/native-activity/main.o ./obj/local/x86/libandroid_native_app_glue.a -lgcc -gcc-toolchain $NDK/toolchains/x86-4.8/prebuilt/linux-x86 -target i686-none-linux-android -no-canonical-prefixes -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -L$NDK/platforms/android-9/arch-x86/usr/lib -llog -landroid -lEGL -lGLESv1_CM -llog -lc -lm -fuse-ld=bfd -L../../../phobos/generated/linux/release/32 -l:libphobos2.a -o ./libs/x86/libnative-activity.so Seems a lot of the paths are wrong/different than what I have $NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang -Wl,-soname,libhello-jni.so -shared --sysroot=$NDK/platforms/android-9/arch-x86 ./obj/local/x86/objs-debug/hello-jni/main.o ./obj/local/x86/libandroid_native_app_glue.a -lgcc -gcc-toolchain $NDK/toolchains/x86-4.8/prebuilt/linux-x86 -target i686-none-linux-android -no-canonical-prefixes -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -L$NDK/platforms/android-9/arch-x86/usr/lib -llog -landroid -lEGL -lGLESv1_CM -llog -lc -lm -fuse-ld=bfd -L../../../phobos/generated/linux/release/32 -l:libphobos2.a -o ./libs/x86/libhello-jni.so I am going to zip of what I have so you can see how the paths are laid out: http://www.filedropper.com/ldc2android There seems to be no obj file generated except for debug, that was probably intentional but the given command line doesn't represent that if so. It is a bit confusing for the beginner to come along and try to get all this to work when there is contradictory information. The reason being is simple in that a beginner won't know what is used for what and the docs essentially are give as "plug and play" yet don't actually work... rather than being descriptive and explaining exactly what is what(some of it should be obvious but not all will be to someone that isn't versed in linux and android development or used to windows which abstracts everything). What would be nice, at a minim, is a bash script that allows one to adjust different variables for different situations and then it can be used to compile. (e.g., set the obj path, ndk path, ldc2 path, etc) What really needs to be done, IMO, is to have a simple set of tools(scripts or whatever) that can be configured easily and abstracts the complexity. (I've done that for the test script I made #!/bin/bash /mnt/c/dlang/ldc2Android/bin/ldc2 -c $1.d $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -Wl,-z,nocopyreloc --sysroot=$NDK/platforms/android-9/arch-arm -lgcc -gcc-toolchain $NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -target armv7-none-linux-androideabi -no-canonical-prefixes -fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fPIE -pie -mthumb -Wl,--export-dynamic -lc -lm $1.o lib/libphobos2-ldc.a lib/libdruntime-ldc.a -o $1 which does the compiling for me without having to type all that junk in each time.. pretty simple but does the job, a more advanced concept could be used to help make it easier on people ) If you want, and you can accomplish this, if there was an ldc2/dmd2 for android that runs on windows I could work on getting it working for windows(as I prefer it rather than linux, which I have no real experience with). I'm thinking everything more or less would work similarly(since sdk/ndk exists for windows). It would just be a matter of translating paths and such. I could easily write a wrapper to reduce the complexity. The main problem I seem to be having are
Re: Getch() Problem: C vs D
On Monday, 9 January 2017 at 19:11:48 UTC, LouisHK wrote: No, that duplicate problem occurs even on normal keys, if I press "a" it shows "aa", and through the WinDBG, I saw the kbhit() was always true 2x after a key is pressed. I think my lib returns on key *release* as well, since it registers that on Windows. Probably a bug, though I don't like using the getch function, I usually use the full input stream.
Re: Delegate parameter name shadows type name
On 2017-01-09 20:18, Ali Çehreli wrote:
This is something that surprised me in a friend's code.
(A "friend", hmmm? No, really, it wasn't me! :) )
// Some type of the API
struct MyType {
int i;
}
// Some function of the API that takes a delegate
void call(void delegate(MyType) dlg) {
dlg(MyType(42));
}
void main() {
/* The programmer simply copied the delegate definition from
* the function and used it as-is when passing a lambda: */
call(delegate void(MyType) {
/* WAT? Does the following really compile? After all,
* MyType.i is NOT a static member! */
if (MyType.i == 42) {
// ...
}
});
}
I was surprised to see it compiled and worked but of course MyType at
the lambda definition inside main() is not a type name, rather the
parameter name. Surprising, but I think this is according to spec.
I know this has come up before, and reported as a bug, at least once.
Might have been me :). What's confusing is that using a type that has a
keyword will make the parameter unnamed of the specified type, just as a
regular function:
auto a = (int) => 3; // works, a lambda taking an int, no parameter name
auto b = (Foo) => 3; // error, cannot infer type of template lambda
alias b = (Foo) => 3; // works, since this is an alias, Foo is the
parameter name of an unknown type
--
/Jacob Carlborg
Re: Delegate parameter name shadows type name
On 01/09/2017 11:23 AM, H. S. Teoh via Digitalmars-d-learn wrote:
> On Mon, Jan 09, 2017 at 11:18:02AM -0800, Ali Çehreli via
Digitalmars-d-learn wrote:
>> // Some function of the API that takes a delegate
>> void call(void delegate(MyType) dlg) {
That's a delegate type.
>> call(delegate void(MyType) {
>
> Are you sure this isn't spelt `void delegate(MyType)`?
Those two syntaxes always confuse me and I'm never sure without trying
which one to use when. :) However, the code is correct in this case
because that's a delegate instance.
Ali
Re: Delegate parameter name shadows type name
On Monday, January 09, 2017 11:18:02 Ali Çehreli via Digitalmars-d-learn
wrote:
> This is something that surprised me in a friend's code.
>
> (A "friend", hmmm? No, really, it wasn't me! :) )
>
> // Some type of the API
> struct MyType {
> int i;
> }
>
> // Some function of the API that takes a delegate
> void call(void delegate(MyType) dlg) {
> dlg(MyType(42));
> }
>
> void main() {
> /* The programmer simply copied the delegate definition from
> * the function and used it as-is when passing a lambda: */
> call(delegate void(MyType) {
> /* WAT? Does the following really compile? After all,
> * MyType.i is NOT a static member! */
> if (MyType.i == 42) {
> // ...
> }
> });
> }
>
> I was surprised to see it compiled and worked but of course MyType at
> the lambda definition inside main() is not a type name, rather the
> parameter name. Surprising, but I think this is according to spec.
Well, stuff inside a function is quite free to shadow stuff from outside of
it. AFAIK, the only shadowing that's prevented is declarations in a function
shadowing other declarations in a function.
- Jonathan M Davis
Re: Delegate parameter name shadows type name
On Mon, Jan 09, 2017 at 11:18:02AM -0800, Ali Çehreli via Digitalmars-d-learn
wrote:
[...]
> // Some type of the API
> struct MyType {
> int i;
> }
>
> // Some function of the API that takes a delegate
> void call(void delegate(MyType) dlg) {
> dlg(MyType(42));
> }
>
> void main() {
> /* The programmer simply copied the delegate definition from
> * the function and used it as-is when passing a lambda: */
> call(delegate void(MyType) {
Are you sure this isn't spelt `void delegate(MyType)`?
> /* WAT? Does the following really compile? After all,
> * MyType.i is NOT a static member! */
> if (MyType.i == 42) {
> // ...
> }
> });
> }
>
> I was surprised to see it compiled and worked but of course MyType at
> the lambda definition inside main() is not a type name, rather the
> parameter name. Surprising, but I think this is according to spec.
[...]
I think it makes sense relative to your rationalization of it per the
spec, but from an objective POV, I think it rightly deserves a WAT?.
I can't see anything useful such a construction would allow, besides
leading to buggy code caused by unexpected shadowing.
I'd say file an enhancement request to make such code a compile error.
T
--
Ph.D. = Permanent head Damage
Delegate parameter name shadows type name
This is something that surprised me in a friend's code.
(A "friend", hmmm? No, really, it wasn't me! :) )
// Some type of the API
struct MyType {
int i;
}
// Some function of the API that takes a delegate
void call(void delegate(MyType) dlg) {
dlg(MyType(42));
}
void main() {
/* The programmer simply copied the delegate definition from
* the function and used it as-is when passing a lambda: */
call(delegate void(MyType) {
/* WAT? Does the following really compile? After all,
* MyType.i is NOT a static member! */
if (MyType.i == 42) {
// ...
}
});
}
I was surprised to see it compiled and worked but of course MyType at
the lambda definition inside main() is not a type name, rather the
parameter name. Surprising, but I think this is according to spec.
Ali
Re: Getch() Problem: C vs D
On Monday, 9 January 2017 at 18:09:21 UTC, Ivan Kazmenko wrote: That's because special keys actually put two characters in the buffer, right? Otherwise, using that buffer alone, you won't be able to distinguish, for example, arrow keys from capital Latin letters with the same codes. No, that duplicate problem occurs even on normal keys, if I press "a" it shows "aa", and through the WinDBG, I saw the kbhit() was always true 2x after a key is pressed. And I think the kbhit() (Like in many other libraries) would only return true, when a key is pressed. I even tried to delay using sleep() after a keystroke, but it still duplicates after I press any key. L.
Re: Android Status
On Monday, 9 January 2017 at 08:28:04 UTC, Joakim wrote:
On Monday, 9 January 2017 at 00:40:35 UTC, Ignacious wrote:
On Sunday, 8 January 2017 at 22:19:31 UTC, Joakim wrote:
On Sunday, 8 January 2017 at 21:52:01 UTC, Ignacious wrote:
Not sure what is going on, of course ;) So much BS just to
do something that is suppose to be simple ;)
test.d
void main()
{
}
here is test.o
http://pastebin.com/NRrKgKtb
Any ideas?
Oh, that's easy: install the NDK too, as shown on the wiki.
You need the linker that supports ARM from the NDK. Follow
the instructions from the wiki to compile and link the
binary, simply having ldc do everything won't work.
Ok, after executing
$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-Wl,-z,nocopyreloc --sysroot=$NDK/platforms/android-9/arch-arm
-lgcc -gcc-toolchain
$NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -target armv7-none-linux-androideabi -no-canonical-prefixes -fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fPIE -pie -mthumb -Wl,--export-dynamic -lc -lm test.o lib/libphobos2-ldc.a lib/libdruntime-ldc.a -o test
I get a test elf file with no errors(although 2.5MB for a
hello world).
I had to do the chmod 755 test
then
./test
to get any output. Before that no output and no errors so
wasn't sure what as going on.
Looks like everything is working! ;)
Good to hear it finally works. :D
Seems like someone really needs to put some time in to getting
all this stuff organized and situated
Maybe the D language foundation can push some money towards it
to get it started off on the right foot?
I'll try to get some of the opengl examples on your repository
to see if they work soon.
I don't think money is the issue as much as people like you
trying it on your own platform and documenting any problems you
find.
ssshhh! Don't say that! Money always help!!! ;)
Cross-compiler toolchains are never simple, consider yourself
lucky for having gotten off easy. :)
I realize things are difficult but it's people that make it
that way ;) Life would be so much simpler if people would just
properly document stuff exactly(or, rather, do what they are
suppose to do). (Even windows seems to love to forget to put
in descriptions of services, tasks, application descriptions,
etc).
I've tried to write up detailed instructions on the wiki. I'm
still improving those and plan to spin off those two sections I
linked you, on how to just build the samples, into their own
page. You can contribute any steps you had to take with
Bash/Ubuntu on Windows with the prebuilt linux/x64
cross-compiler there, once I put the page up.
Yeah, I found it a bit confusing though. It seems like it is
written up by someone that is working on the core rather than a
newb! ;)
The main problem I have had seems to be that UoW uses ver 14.
Somehow I was able to upgrade by following docs online(wasn't
easy but eventually got there and everything seems to work...
I should have documented ;) but I wasn't sure if the process
would work. Supposedly ver 16 exists by one has to be part of
the dev team or something.
If you know all the steps to upgrade Ubuntu on Windows, you may
want to document them on the wiki page I will put up or link to
a good resource that shows how to do it.
I don't because it was all new to me(I didn't know there was even
such a thing as UoW. I simply searched for the errors I got and
tried different solutions until it worked. Luckily the outcome
worked... which is not always the case.
I think that it would be a boon for D to have some type of well
defined and well planned Android development suite rather than
what seems to be hacked/cobbled together. This would bring not
only more developers to D for android but also to D in general.
I'm gonna try the opengl examples and hopefully the work. The
main problem I see is how to actually write "commercial" apps
using D for android. Can it be done successfully? Nobody knows
because there isn't a history. What are the exact steps, say, to
add ads, or interface with the subsystem? I saw that there is
some way to call some java stuff from D but seems like nothing is
thoroughly tested(most of the work as been just trying to get
things up and running).
I will try to do a better job of documenting my progress now that
I have some faith ;) But right now I'm more of the horse rather
than the guy trying to show him where the water is.
Loading assimp
I'm trying to use assimp to load models in a program. I see the Derelict binding is for version 3.3, but the assimp site has no binaries for this, just source. So I try to use version 3.1.1 and I get this error: derelict.util.exception.SymbolLoadException@..\..\AppData\Roaming\dub\packages\derelict-util-2.0.6\derelict-util\source\derelict\util\exception.d(35): Failed to load symbol aiReleaseExportFormatDescription from shared library assimp.dll Is this a version problem that I need 3.3 for? If so, I don't know how to build the .dll since I'm still new to programming. Please send help! :)
Re: Getch() Problem: C vs D
On Monday, 9 January 2017 at 13:10:30 UTC, Adam D. Ruppe wrote:
...
Best solution is to skip those C library functions and do it
yourself with the OS-level calls. Then you can turn it off and
actually control the buffering behavior.
That's what I was afraid of. I even tried your terminal.d, and it
worked for those keys above, but unfortunately it's duplicating
the values, one little example (From your source):
if(input.kbhit()){
auto c = input.getch();
write(c);
}
As I could see with WinDBG, the condition "input.kbhit()" is true
for the first 2 times after I hit a key.
L.
Re: Getch() Problem: C vs D
On Sunday, 8 January 2017 at 21:19:15 UTC, LouisHK wrote: And works fine, but the D version below nothing happens when I hit ESCAPE: Different runtimes are free to line buffer data, meaning getch won't actually see anything until you hit enter. (Actually, the operating system does the buffering unless the runtime specifically asks it not to.) Looks like your C library (gcc? asks the OS not to buffer, and the D (digital mars or Microsoft, DM on 32 bit, MS on 64 bit) turn it off. Best solution is to skip those C library functions and do it yourself with the OS-level calls. Then you can turn it off and actually control the buffering behavior.
Re: Getch() Problem: C vs D
On Monday, 9 January 2017 at 04:31:04 UTC, Era Scarecrow wrote: On Sunday, 8 January 2017 at 21:19:15 UTC, LouisHK wrote: ... Regardless, try ^[ ( Ctrl+[ ), which is 27 and ^] is 29. Interesting, I'll try that at home. And maybe it will work. One more thing: I had tried the C version with gcc compiler, and it worked ok. But with DMC (Digital Mars Compiler) like DMD it does nothing when I hit (ESCAPE, INSERT, DELETE...). So I think this is a behaviour from Digital Mars compilers. L.
Re: Conditional Compilation Multiple Versions
Druntime uses this for its translation of POSIX header files: https://github.com/dlang/druntime/blob/master/src/core/sys/posix/config.d An example: https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/resource.d#L96 Ok, I see. Thanks! (I've gotta try reggae someday) :)
Re: Android Status
On Monday, 9 January 2017 at 00:40:35 UTC, Ignacious wrote:
On Sunday, 8 January 2017 at 22:19:31 UTC, Joakim wrote:
On Sunday, 8 January 2017 at 21:52:01 UTC, Ignacious wrote:
Not sure what is going on, of course ;) So much BS just to do
something that is suppose to be simple ;)
test.d
void main()
{
}
here is test.o
http://pastebin.com/NRrKgKtb
Any ideas?
Oh, that's easy: install the NDK too, as shown on the wiki.
You need the linker that supports ARM from the NDK. Follow
the instructions from the wiki to compile and link the binary,
simply having ldc do everything won't work.
Ok, after executing
$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-Wl,-z,nocopyreloc --sysroot=$NDK/platforms/android-9/arch-arm
-lgcc -gcc-toolchain
$NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64
-target armv7-none-linux-androideabi -no-canonical-prefixes
-fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fPIE -pie -mthumb
-Wl,--export-dynamic -lc -lm test.o lib/libphobos2-ldc.a
lib/libdruntime-ldc.a -o test
I get a test elf file with no errors(although 2.5MB for a hello
world).
I had to do the chmod 755 test
then
./test
to get any output. Before that no output and no errors so
wasn't sure what as going on.
Looks like everything is working! ;)
Good to hear it finally works. :D
Seems like someone really needs to put some time in to getting
all this stuff organized and situated
Maybe the D language foundation can push some money towards it
to get it started off on the right foot?
I'll try to get some of the opengl examples on your repository
to see if they work soon.
I don't think money is the issue as much as people like you
trying it on your own platform and documenting any problems you
find.
Cross-compiler toolchains are never simple, consider yourself
lucky for having gotten off easy. :)
I realize things are difficult but it's people that make it
that way ;) Life would be so much simpler if people would just
properly document stuff exactly(or, rather, do what they are
suppose to do). (Even windows seems to love to forget to put in
descriptions of services, tasks, application descriptions, etc).
I've tried to write up detailed instructions on the wiki. I'm
still improving those and plan to spin off those two sections I
linked you, on how to just build the samples, into their own
page. You can contribute any steps you had to take with
Bash/Ubuntu on Windows with the prebuilt linux/x64 cross-compiler
there, once I put the page up.
The main problem I have had seems to be that UoW uses ver 14.
Somehow I was able to upgrade by following docs online(wasn't
easy but eventually got there and everything seems to work... I
should have documented ;) but I wasn't sure if the process
would work. Supposedly ver 16 exists by one has to be part of
the dev team or something.
If you know all the steps to upgrade Ubuntu on Windows, you may
want to document them on the wiki page I will put up or link to a
good resource that shows how to do it.
