Re: Problems with Array Assignment?
On Wednesday, 10 May 2017 at 20:01:16 UTC, Adam D. Ruppe wrote: ... Thanks loads. Thanks to this my next commit is going to have quite a few improvements that clean up the engine code considerably. I appreciate the help.
Re: Problems with Array Assignment?
On Wednesday, 10 May 2017 at 17:54:38 UTC, Adam D. Ruppe wrote: On Wednesday, 10 May 2017 at 17:47:57 UTC, Samwise wrote: The expected behavior for this is to just see "Different Text" and "Other Text", instead of having any time to see just "Text". However, it seems that the second update method is having the effect that the first call should, and then the second is being called after the waiting. My guess is just output buffering from consoled. Try `import std.stdio;` and `stdout.flush();` after each update and see what happens. I'm in a work meeting right now, i can look more after if this isn't it (and I will answer your other email too) Thanks a lot, that hit the nail on the head. Behaves exactly as I expected it to.
Re: Problems with Array Assignment?
I'm also having another problem with this program that is (sorta?) related. If you notice in my main (minus all the comments...), the code creates two tiles, then updates the renderer so that it renders those tiles. Then I create another tile in the same place as one of the first ones (not strictly relevant) and updates. Then the program pauses before it exits. The expected behavior for this is to just see "Different Text" and "Other Text", instead of having any time to see just "Text". However, it seems that the second update method is having the effect that the first call should, and then the second is being called after the waiting. Could anyone offer any insight on this? Again I'm sure it's an issue that I could have avoided had I known more when I wrote the code, but just don't yet. Thanks again for the help. ~Sam
Re: Problems with Array Assignment?
On Wednesday, 10 May 2017 at 13:43:54 UTC, Adam D. Ruppe wrote:
In your code, I see one big mistake:
---
class TileRenderer
{
private Tile[] tiles;
/*...*/
}
class CTileRenderer : TileRenderer
{
private CTile[] tiles;
/*...*/
}
---
Those are two separate arrays! Stuff examined through
TileRenderer will be looking at a different array than looking
through CTileRenderer.
I wondered about that when I did it, but I assumed (wrongly) that
since the name of the array was the same, it would override it.
Thank you for suggesting that I make rendering a tile's
responsibility instead of the renderer's. It honestly makes more
sense that way, and my code is cleaner because of it. I did
actually get it working because of that.
Just to clarify, you can use a superclass variable to reference a
member of a subclass? That seems to be what's happening.
Thanks so much guys, I really appreciate it. My code it working
now, and it's committed to github, so you can check it out if
you'd like. Thanks!
~Sam
Problems with Array Assignment?
I'm really sure this is just a stupid mistake I made, but I can't for the life of me figure out what is going on. Basically I'm trying to assign a reference to an object to an array, and the objects exist (an explicit destructor is writing lines at the end of the program, when the objects are GC'd), but there are not references to them in the array. You can see the complete code, and the line that I think is giving me trouble here: https://github.com/MggMuggins/TrafficLights/blob/master/source/renderer.d#L146 Any help is greatly appreciated. Like I said, I'm sure it's just a silly mistake because I don't understand something, but I appreciate any time you waste on me all the same. Thanks, ~Sam
Re: DMD Refuses to Compile Multiple Source Files
On Wednesday, 18 January 2017 at 04:25:42 UTC, Mike Parker wrote: extern(C), not simply extern. It turns off the name mangling. But really, the proper thing to do is to drop the prototype and import the module with the implementation. It's tge way modules are intended to be used. Unless you're doing something specidic like writing a library that calls an arbitrary user function. Alright, so I misunderstood what ketmar was saying. His solution did work. I'm just not sure I understand what you are trying to say here: I've started using dub for things, and I've learned a lot since this thread. Anyway, thanks for the support with this everybody.
Re: Problems with setting up dub for publication
On Sunday, 5 March 2017 at 01:54:22 UTC, Mike Parker wrote: ... I was getting the same problem and created on issue on this project's repository (https://github.com/ZILtoid1991/pixelperfectengine), which I think (although I don't know) was the reason this thread was created. Using the dub.json that I added in that PR will compile. However, since I didn't actually write any code, I doubt that if I imported anything from pixelperfect that it would still work. This is an issue I saw somewhere else... Anyway, building "pixelperfectengine:pixelperfectengine": "*" works with the hello world app.d, although like I said, probably will not if I try to import anything from pixelperfect. Building "pixelperfectengine": "~>0.9.1-rc2" does not work, it still gives me the linker error from the top of this thread. I like dub too. It has worked well for me and seems to be much lighter and less of a mess than at least some IDE's. Right now I finished fixing the d-struct package for the atom text editor, which adds dub support for that, so I don't have to use the command line hardly at all :P. In any case, dub is a great tool, and works well most of the time.
Re: Returning Arrays from Functions
On Wednesday, 18 January 2017 at 23:09:15 UTC, Adam D. Ruppe wrote: On Wednesday, 18 January 2017 at 22:51:17 UTC, Samwise wrote: numbs[] = getInp(help, file, inp, args); This is wrong, try just `numbs = getImp(...);` numbs[] = xxx will copy stuff into the existing array, which is empty right now. You want to jut keep the slice the function passes back. Huh. I thought I tried that. I guess I didn't, since it worked like a charm. Thanks loads. ~Sam
Re: DMD Refuses to Compile Multiple Source Files
Thanks loads. I got it working using those modules. ~Sam
Re: Returning Arrays from Functions
On Wednesday, 18 January 2017 at 22:37:25 UTC, Adam D. Ruppe
wrote:
What code do you have now?
This is the basic function. It takes all those boolean arguments
and does things depending on them, and then takes any extra args
that getopt didn't parse and reads them into numbs. That code
works fine, because I write it out after that's done but before I
pass it back to main().
ulong[] getInp (bool help, bool file, bool inp, string[] args) {
//...
writeln(numbs);
return numbs;
}
Here is what I've got in main (Minus some more stuff). Right now
it's just printing out what it gets, but it will use other
functions to apply operations to numbs later.
int main(string[] args) {
ulong[] numbs;
//...
numbs[] = getInp(help, file, inp, args);
writeln(numbs);
return 0;
}
That prints out an empty array. If I initialize one element,
(numbs[0] ~= 0;) then it prints out numbs.length. Really kinda
weird... Thanks,
~Sam
Returning Arrays from Functions
I've done a whole bunch of looking around, and I don't see any mention of returning a dynamic array from a function. When I try it though, it just returns the .length value of the array, rather than the contents of the array. Does anyone know why this is, and what I can do to make it behave the way I want it to?
Re: DMD Refuses to Compile Multiple Source Files
On Wednesday, 18 January 2017 at 04:25:42 UTC, Mike Parker wrote: extern(C), not simply extern. It turns off the name mangling. But really, the proper thing to do is to drop the prototype and import the module with the implementation. It's tge way modules are intended to be used. Unless you're doing something specidic like writing a library that calls an arbitrary user function. Alright, so I misunderstood what ketmar was saying. His solution did work. I'm just not sure I understand what you are trying to say here: But really, the proper thing to do is to drop the prototype and import the module with the implementation. This will still preserve my multiple source files, without worrying about the headers, right? Thanks, ~Sam
Re: DMD Refuses to Compile Multiple Source Files
On Wednesday, 18 January 2017 at 03:51:50 UTC, ketmar wrote:
On Wednesday, 18 January 2017 at 03:37:46 UTC, Samwise wrote:
extern int getReturnCode() {
return 4;
}
still does not compile using the command from above. I may
very well be misunderstanding you though.
yep. *both* prototype and real declaration should be
`extern(C)`. `(C)` part is important too!
I have both the header in hello.d and the actual function in
getReturnCode.d as extern, and it still fails with the same error.
Re: DMD Refuses to Compile Multiple Source Files
On Wednesday, 18 January 2017 at 03:25:47 UTC, Stefan Koch wrote:
On Wednesday, 18 January 2017 at 03:11:08 UTC, Samwise wrote:
On Wednesday, 18 January 2017 at 02:48:45 UTC, James Buren
wrote:
Import the source file containing the external function
instead of writing that prototype. It should compile then.
This seems like a workaround more than a permanent solution.
It would work, but still. I'm also not sure about the syntax
for that (Given that getReturnCode.d is in the same directory
as hello.d).
~Sam
In extern (D) functions (which is the default)
The module name is part of the mangled name.
What you are trying to do would work ,
if the getReturnType would be extern(C).
Without changing anything about the hello.d file from above, and
the only change being adding the extern keyword to the
getReturnValue.d like this:
extern int getReturnCode() {
return 4;
}
still does not compile using the command from above. I may very
well be misunderstanding you though. I've not been doing this
particularly long...
~Sam
Re: DMD Refuses to Compile Multiple Source Files
On Wednesday, 18 January 2017 at 02:48:45 UTC, James Buren wrote: Import the source file containing the external function instead of writing that prototype. It should compile then. This seems like a workaround more than a permanent solution. It would work, but still. I'm also not sure about the syntax for that (Given that getReturnCode.d is in the same directory as hello.d). ~Sam
DMD Refuses to Compile Multiple Source Files
Alright. For the sake of this argument, I'm going to post all the
stuff about a really tiny boring program that quite literally
does nothing, even though I found this issue when I was working
with a much larger project with more functions. Basically I'm
getting errors when I attempt to compile multiple source files
using the DMD. It does not matter whether it's through dub or
just straight DMD. A few little code snippets and DMD output (The
dub output is basically the same as the DMD, just with a few more
lines):
hello.d (This file contains the main function, as you can see. I
put the headers in here to simplify things.):
import std.stdio;
int getReturnCode();
int main() {
writeln("Hello World!");
return getReturnCode();
}
getReturnCode.d (This file is the home of my cute function, which
does nothing...):
int getReturnCode() {
return 4;
}
Those were the complete contents of my two basic program files.
The Compilation works fine (Can generate both object files using
the -c switch with the DMD). However, it just stops when
linking...
$ dmd getReturnCode.d hello.d
getReturnCode.o: In function `_Dmain':
hello.d:(.text._Dmain+0x17): undefined reference to
`_D5hello13getReturnCodeFZi'
collect2: error: ld returned 1 exit status
--- errorlevel 1
This basic output is what I'm getting whenever I try to compile a
main function using a function call that is for a function not
included in the main.d, regardless of pretty much any other thing.
Thank you for reading and at least attempting to help me solve
this issue...
~Sam
