Re: D and .lib files. C++/Other?
K im retarded... So I forgot the golden rule, debug libs with debug app, release libs with release app.. I attempted loading the debug version of dll with D again just to see what kinda errors (may) come up there, sure enough there is and i get a fairly detailed one... However, when the function ConsoleWrite is called in either project, it goes back to the close bracket on the myclass.d page(The original myclass.d from the actual dll source code) and then re[prts stdio.d "in gc_malloc" At this point I am thoroughly confused... It has only done this since adding the extern(C) tag to the source... even changing that to C++(Where depends.exe reports a garbled mess of a name again) still reports the same issue.
Re: D, Game Development, GLSL, Math
On Saturday, 1 July 2017 at 19:23:57 UTC, Void-995 wrote: Looking good, but I'm thinking more about 1:1 GLSL syntax (main reason - rapid prototype of GLSL/HLSL/OpenCL in D and code portability back and forward basing on usage) and heavy depending on SIMD. Just math and nothing else. Also may be a nice excersise for myself. You can just depend on the subpackage gfm:math. Is 1:1 GLSL syntax that good? In GLSL: - per-item max is just called "max" which clashes with Phobos. Most GLSL function names clash with Phobos which creates errors when both are imported. - mat3x4 is a 3 column by 4 rows types, which is kind of a trap. - vec4 does not say it's 4 floats whereas vec4f does - "lerp" might be a better name than "mix" - etc...
Re: D, Game Development, GLSL, Math
On Saturday, 1 July 2017 at 19:07:48 UTC, Void-995 wrote: can i use simd as base to extend it's syntax for making something like GLM for C++? You can use simd to implement something like GLM, but extending the syntax of SIMD will prove more difficult. vector types are a bit different in LDC and DMD, also DMD 32-bit won't support D_SIMD. https://github.com/jkrempus/pfft is the only library I know that abstracts over the varied D SIMD capabilities, and possibly work with all compilers.
Re: D and .lib files. C++/Other?
Well I ended up getting it to compile finally by adding extern "C" before the function imports on C++ side (Again i added the extern(C) to D side) however i still end up not being able to run the program as it keeps telling me: 0xC005: Access violation reading location 0x Ive been googling this for a while but can't seem to figure out what causes it aside from the general concensus being "Im trying to access a null pointer" but neither side of my code as far as i can tell actually attempts this... any ideas?
Re: D and .lib files. C++/Other?
If you're wanting to use the names (e.g. "ConsoleWrite") as is on the C++ side them you need to declare them extern(C++) ( or extern(C)) on the D side. if you were to run whatever the equivalent of "nm my.dll | grep Console" on windows on the dll then you'd see the two symbols with a different name (i.e. not __imp_?ConsoleWrite@myclass@@SAXXZ). Thanks for the reply. Ive generated one using the extern(C) tag now, and checked it in Depends.exe(Dependency Walker) it now shows the Entry Point names as the correct names which is good news i really appreciate that. Its progress! Though i still retain the errors when trying to run it with C++.
Re: std.string.format call from varyargs
On Sunday, 2 July 2017 at 00:49:30 UTC, LeqxLeqx wrote:
Hello!
How does one go about invoking a templated-variatic function
such as std.string.format
with an array of objects?
For example:
string stringMyThing (string formatForMyThings, MyThing[]
myThings)
{
return format(
formatForMyThings,
myThings
);
}
In executing the above, the 'format' method always interprets
the entire array 'myThings' as the first argument to the
format, and no arguments afterwards, resulting in 'orphaned'
format specifiers if the array is longer than a single element.
Even if the array is only a single element, the formatter will
wrap the result of the element's 'toString()' method with '['
and ']'
I really don't want to write my own format parser.
Any help would be much appreciated!
Thanks!
string stringMyThing (string fmt, MyThing[] myThings)
{
Appender!(string) s;
foreach(thing; myThings);
s.append(format(fmt,thing));
return s.data();
}
sorry I can't remember the appender api properly.
Re: weird error message
On 07/01/2017 04:56 PM, crimaniak wrote: > about very long error messages generated in some > cases. Please submit a bug report. The compiler may be able to abbreviate certain types. For example, in this case most of the error message text is values of a static array elements. Ali
std.string.format call from varyargs
Hello!
How does one go about invoking a templated-variatic function such
as std.string.format
with an array of objects?
For example:
string stringMyThing (string formatForMyThings, MyThing[]
myThings)
{
return format(
formatForMyThings,
myThings
);
}
In executing the above, the 'format' method always interprets the
entire array 'myThings' as the first argument to the format, and
no arguments afterwards, resulting in 'orphaned' format
specifiers if the array is longer than a single element. Even if
the array is only a single element, the formatter will wrap the
result of the element's 'toString()' method with '[' and ']'
I really don't want to write my own format parser.
Any help would be much appreciated!
Thanks!
Re: D, Game Development, GLSL, Math
On Saturday, 1 July 2017 at 19:23:57 UTC, Void-995 wrote: On Saturday, 1 July 2017 at 19:16:12 UTC, drug wrote: 01.07.2017 22:07, Void-995 пишет: (Void-995) Hi, everyone. I'm pretty excited with what have D to offer for game development, especially meta programming, traits, object.factory, signals and bunch of other neat things that may save a lot of time. Also, i saw support for vector data types and simd, which sounds awesome. The question is, can i use simd as base to extend it's syntax for making something like GLM for C++? I mean extending existing types with new operators and such to have GLSL/HLSL like syntax for basis math operation in D? Maybe someone did that already? Look at gfm https://code.dlang.org/packages/gfm Looking good, but I'm thinking more about 1:1 GLSL syntax (main reason - rapid prototype of GLSL/HLSL/OpenCL in D and code portability back and forward basing on usage) and heavy depending on SIMD. Just math and nothing else. Also may be a nice excersise for myself. "Changing the syntax" can be done (e.g. https://github.com/p0nce/intel-intrinsics) You'll want to look at the operator overloading that can be done in D (spec https://dlang.org/spec/operatoroverloading.html) As a side note: I'll soon be starting work on DCompute[1] again (Honours thesis due tomorrow), integrating John Colvin's CLWrap among many other things. [1]https://github.com/libmir/dcompute
Re: weird error message
On Saturday, 1 July 2017 at 22:46:06 UTC, Adam D. Ruppe wrote: On Saturday, 1 July 2017 at 22:44:33 UTC, crimaniak wrote: enum moduleMask = ctRegex!`module\s+([^;]+)`; That should be `static`, not `enum`. I betcha that will at least change the error. Works both variants, and reason really in line with Captures c = ..., as mentioned Ali Çehreli. But my message not about this mistake (I fix it immediately), but about very long error messages generated in some cases. Maybe it will be good to have some compiler switch or special treatment for messages with so very long types.
Re: D and .lib files. C++/Other?
On Saturday, 1 July 2017 at 20:47:55 UTC, Damien Gibson wrote:
Well I finally somehow got it to stop complaining about a bad
lib file, but now it wants to tell me the entry point for the
functions i list isnt correct, so now im just unsure if its
being stupid on me or im not writing something write on the D
or C++ end...
The D code:
___
import std.stdio;
export:
void ConsoleWrite()
{
writeln("This is a test written in DLang/DMD!");
}
void ConsoleWait()
{
readln();
}
___
i imported the stuff on CPP and tried to call it.. this is the
hpp file:
myclass.hpp:
___
#pragma once
#ifdef _MYDLL_EXPORTS
#define DllAPI __declspec(dllexport)
#else
#define DllAPI __declspec(dllimport)
#endif
DllAPI void ConsoleWrite();
DllAPI void ConsoleWait();
___
The errors:
___
2 error LNK1120: 1 unresolved externals
1 error LNK2019: unresolved external symbol
"__declspec(dllimport) void __cdecl ConsoleWrite (void)"
(__imp_?ConsoleWrite@myclass@@SAXXZ) referenced in function
_wmain
___
If you're wanting to use the names (e.g. "ConsoleWrite") as is on
the C++ side them you need to declare them extern(C++) ( or
extern(C)) on the D side. if you were to run whatever the
equivalent of "nm my.dll | grep Console" on windows on the dll
then you'd see the two symbols with a different name (i.e. not
__imp_?ConsoleWrite@myclass@@SAXXZ).
Re: weird error message
On 07/01/2017 03:44 PM, crimaniak wrote: > Captures c = findModule.output.matchFirst!(moduleMask); > > result (even C++ guys will be impressed): > > phobos_imports.d(43): Error: struct std.regex.Captures(R, DIndex = > size_t) if (isSomeString!R) is used as a type From the error message, it looks like Captures is a template. You can't use it as a type simply as 'Captures'. Better use 'auto' in its place: auto c = /* ... */ Ali
Re: weird error message
On Saturday, 1 July 2017 at 22:44:33 UTC, crimaniak wrote: enum moduleMask = ctRegex!`module\s+([^;]+)`; That should be `static`, not `enum`. I betcha that will at least change the error.
weird error message
Just for fun (may be): code: auto findModule = execute(["dscanner", "--etags", entry.name]); enum moduleMask = ctRegex!`module\s+([^;]+)`; Captures c = findModule.output.matchFirst!(moduleMask); result (even C++ guys will be impressed): phobos_imports.d(43): Error: struct std.regex.Captures(R, DIndex = size_t) if (isSomeString!R) is used as a type phobos_imports.d(43): Error: template std.regex.matchFirst cannot deduce function from argument types !(StaticRegex(& func, Regex([InversionList(CowArray([9u, 14u, 32u, 33u, 133u, 134u, 160u, 161u, 5760u, 5761u, 8192u, 8203u, 8232u, 8234u, 8239u, 8240u, 8287u, 8288u, 12288u, 12289u, 3u])), InversionList(CowArray([0u, 59u, 60u, 1114112u, 3u]))], [Bytecode(2147483757u), Bytecode(2147483759u), Bytecode(2147483748u), Bytecode(2147483765u), Bytecode(2147483756u), Bytecode(2147483749u), Bytecode(2348810240u), Bytecode(2231369729u), Bytecode(2348810240u), Bytecode(2248146945u), Bytecode(0u), Bytecode(2952790017u), Bytecode(2281701377u), Bytecode(2231369729u), Bytecode(2281701377u), Bytecode(2248146945u), Bytecode(1u), Bytecode(3019898881u), Bytecode(2550136833u)], null, 2u, 0u, 2u, 17u, 0u, [CharMatcher(BitTable([15872u, 1u, 0u, 0u]), Trie(MultiArray([0LU, 2048LU], [8192LU, 1536LU], [281479271743488LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281483566710785LU, 281479271743489LU, 281479271743489LU, 281479271743491LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743492LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU, 281479271743489LU,
Re: D and .lib files. C++/Other?
Well I finally somehow got it to stop complaining about a bad lib
file, but now it wants to tell me the entry point for the
functions i list isnt correct, so now im just unsure if its being
stupid on me or im not writing something write on the D or C++
end...
The D code:
___
import std.stdio;
export:
void ConsoleWrite()
{
writeln("This is a test written in DLang/DMD!");
}
void ConsoleWait()
{
readln();
}
___
i imported the stuff on CPP and tried to call it.. this is the
hpp file:
myclass.hpp:
___
#pragma once
#ifdef _MYDLL_EXPORTS
#define DllAPI __declspec(dllexport)
#else
#define DllAPI __declspec(dllimport)
#endif
DllAPI void ConsoleWrite();
DllAPI void ConsoleWait();
___
The errors:
___
2 error LNK1120: 1 unresolved externals
1 error LNK2019: unresolved external symbol
"__declspec(dllimport) void __cdecl ConsoleWrite (void)"
(__imp_?ConsoleWrite@myclass@@SAXXZ) referenced in function _wmain
___
Re: D, Game Development, GLSL, Math
On Saturday, 1 July 2017 at 19:16:12 UTC, drug wrote: 01.07.2017 22:07, Void-995 пишет: (Void-995) Hi, everyone. I'm pretty excited with what have D to offer for game development, especially meta programming, traits, object.factory, signals and bunch of other neat things that may save a lot of time. Also, i saw support for vector data types and simd, which sounds awesome. The question is, can i use simd as base to extend it's syntax for making something like GLM for C++? I mean extending existing types with new operators and such to have GLSL/HLSL like syntax for basis math operation in D? Maybe someone did that already? Look at gfm https://code.dlang.org/packages/gfm Looking good, but I'm thinking more about 1:1 GLSL syntax (main reason - rapid prototype of GLSL/HLSL/OpenCL in D and code portability back and forward basing on usage) and heavy depending on SIMD. Just math and nothing else. Also may be a nice excersise for myself.
Re: D, Game Development, GLSL, Math
01.07.2017 22:07, Void-995 пишет: (Void-995) Hi, everyone. I'm pretty excited with what have D to offer for game development, especially meta programming, traits, object.factory, signals and bunch of other neat things that may save a lot of time. Also, i saw support for vector data types and simd, which sounds awesome. The question is, can i use simd as base to extend it's syntax for making something like GLM for C++? I mean extending existing types with new operators and such to have GLSL/HLSL like syntax for basis math operation in D? Maybe someone did that already? Look at gfm https://code.dlang.org/packages/gfm
Re: D and .lib files. C++/Other?
Not sure if this is the issue you're having, but if you're using .lib files on Windows, note that DMD, the D compiler, will by default, on 32bit, output a format (OMF) that is not compatible what Visual Studio is using (COFF). For 64bit, DMD outputs COFF .lib files. For 32bit, use the -m32mscoff flag. I do happen to be on 32bit only machine right now, my last pc broke recently lol but yeah i tried that mscoff flag which gave me the conclusion listed above maybe I'm supposed to use another compiler (or maybe i needed more flags than just that) Mixing C++ and D DLLs should work. If you're statically linking the DLL, which requires import libraries on Windows, you might have the above issue. I assumed so that it SHOULD work, as i found multiple documents online talking about using them together but non specifying if there should be special stuff you would have to do on making dlls that mix them As well I only intended to use shared libraries not static ones... I did see a lot of stuff talking about loading the dlls from some special code you would place in your app to load them manually which gave me concerns maybe using .lib files were not possible between the langs -> Which prompted me to come here for help as a last resort.
D, Game Development, GLSL, Math
(Void-995) Hi, everyone. I'm pretty excited with what have D to offer for game development, especially meta programming, traits, object.factory, signals and bunch of other neat things that may save a lot of time. Also, i saw support for vector data types and simd, which sounds awesome. The question is, can i use simd as base to extend it's syntax for making something like GLM for C++? I mean extending existing types with new operators and such to have GLSL/HLSL like syntax for basis math operation in D? Maybe someone did that already?
Re: D and .lib files. C++/Other?
On 2017-07-01 20:13, Damien Gibson wrote: Hi... A while back i had some issues with making a usable dll file, to which i did manage to figure out... Though while trying to use it with C++ i kept getting an error about a corrupted lib file... Not sure if this is the issue you're having, but if you're using .lib files on Windows, note that DMD, the D compiler, will by default, on 32bit, output a format (OMF) that is not compatible what Visual Studio is using (COFF). For 64bit, DMD outputs COFF .lib files. For 32bit, use the -m32mscoff flag. I had in mind the idea to create a few dlls as me and a few friends(Mixed between C++ users and D) but as the issue above I'm not sure if I'm doing something wrong or if that's just not a possibility, I'm not quite sure WHAT I'm needing to look for to find the information about .lib files and how the work and all that cause i haven't been able to find anything if there is anything. Mixing C++ and D DLLs should work. If you're statically linking the DLL, which requires import libraries on Windows, you might have the above issue. -- /Jacob Carlborg
Re: D and .lib files. C++/Other?
Note: I am only on windows as well so i have no idea if the issue remains the same for Linux and it may be a windows specific issue? Also I was using Visual Studio 2013 C++ so i have no idea if its limited to issues there either, I'm on super slow internet (Not dialup but might as well be) So i haven't had the ability to just download a crap ton of tools and try different shit until i got results on my own. (I've done that already within my own ability)
D and .lib files. C++/Other?
Hi... A while back i had some issues with making a usable dll file, to which i did manage to figure out... Though while trying to use it with C++ i kept getting an error about a corrupted lib file... I had in mind the idea to create a few dlls as me and a few friends(Mixed between C++ users and D) but as the issue above I'm not sure if I'm doing something wrong or if that's just not a possibility, I'm not quite sure WHAT I'm needing to look for to find the information about .lib files and how the work and all that cause i haven't been able to find anything if there is anything. So from anyone here who's experienced with this stuff (As i can find resources about making mixed C++ and D project but nothing to do with .lib issues) is it possible to use shared libraries between C++ and D, if so is it 2 sided(where each can use the others produced dll) or 1 sided (one can use the others but not vice versa) as well I had the idea maybe the DMD stuff produces incompatible lib files maybe and another compiler or a command can produce a compatible one... i have no idea so any suggestions are welcome and thank you in advanced for your response!
Re: rank of range
01.07.2017 20:33, Ali Çehreli пишет:
On 07/01/2017 10:05 AM, drug wrote:
Hello!
Is there a convenient way to get rank of range a.k.a. count of
dimensions in compile time? Like:
static assert( rankOf!(uint[]) == 1);
static assert( rankOf!(uint[][][]) == 3);
I'm not aware of one but this seems to work:
template rankOf(R) {
import std.range : isInputRange, ElementType;
static if (isInputRange!R) {
enum rankOf = rankOf!(ElementType!R) + 1;
} else {
enum rankOf = 0;
}
}
unittest {
static assert (rankOf!long == 0);
static assert (rankOf!(int[]) == 1);
static assert (rankOf!(int[][][]) == 3);
}
void main() {
}
Ali
That's what I've done exactly)) Except I didn't tested against long.
Thanks for reply!
Re: rank of range
On 07/01/2017 10:05 AM, drug wrote:
Hello!
Is there a convenient way to get rank of range a.k.a. count of
dimensions in compile time? Like:
static assert( rankOf!(uint[]) == 1);
static assert( rankOf!(uint[][][]) == 3);
I'm not aware of one but this seems to work:
template rankOf(R) {
import std.range : isInputRange, ElementType;
static if (isInputRange!R) {
enum rankOf = rankOf!(ElementType!R) + 1;
} else {
enum rankOf = 0;
}
}
unittest {
static assert (rankOf!long == 0);
static assert (rankOf!(int[]) == 1);
static assert (rankOf!(int[][][]) == 3);
}
void main() {
}
Ali
rank of range
Hello! Is there a convenient way to get rank of range a.k.a. count of dimensions in compile time? Like: static assert( rankOf!(uint[]) == 1); static assert( rankOf!(uint[][][]) == 3);
Re: ReadProcessMemory + address from ollydbg
On Saturday, 1 July 2017 at 00:48:01 UTC, bauss wrote:
On Saturday, 1 July 2017 at 00:40:11 UTC, ag0aep6g wrote:
[...]
Yeah, the cast was unnecessary.
So this is my code after the changes:
string ReadWinString(HANDLE process, DWORD address, size_t
stringSize, string defaultValue = "") {
if (!process || !address) {
return defaultValue;
}
[...]
I have solved the problem. It was caused by an invalid address,
so the code actually worked fine.
Re: How to partially apply member functions?
On Friday, 30 June 2017 at 08:43:32 UTC, ct wrote:
It compiled when I wrote:
auto on_next_previous =
entry_.addOnNextMatch(!(on_next_previous, true));
entry_.addOnPreviousMatch(!(on_next_previous, false));
But not when I wrote:
entry_.addOnNextMatch(partial!(,
true));
Or
entry_.addOnNextMatch(partial!(,
true));
Error: value of 'this' is not known at compile time
In the first snippet, you are passing the local variable
on_next_previous by alias to the template and not the function
AFAIK, when the partial function is
invoked at a later point of time, it will use the value of the
variable at the invocation time and not the value of the variable
at the time of the invocation of partial! template. The following
snippet should clarify this.
import std.stdio;
import std.traits;
template partial(alias f, alias arg1, T = Parameters!f[1])
{
auto g(T arg2)
{
return f(arg1, arg2);
}
enum partial =
}
int foo(int x, int y)
{
writeln("foo");
return x + y;
}
struct bar
{
int id;
int baz(int x, int y)
{
writeln("bar.baz", id);
return x + y;
}
}
void main()
{
auto foo2 = partial!(foo, 2);
writeln(foo2(3));
auto b = bar(0);
auto bbaz =
auto bar2 = partial!(bbaz, 2);
writeln(bar2(3)); // bar.baz0 5
auto c = bar(1);
bbaz =
writeln(bar2(3)); // bar.baz1 5
}
One might think that in the above code, bar2 is set to the
partial function b.baz(2, *). But, it is clear that that is not
the case. There is no partially applied function here. When bar2
is invoked, it invokes the function in the variable bbaz with the
argument given at the time of the template invocation and the
argument given during function invocation.
The snippet
partial!(, true)
doesn't work because templates cannot accept runtime values as
arguments since they work at compile time. The only things that
are available at compile time are symbols and literal values.
Hope this makes sense.
