« first day (676 days earlier)      last day (1994 days later) » 

nathan rogers
nathan rogers
12:26 AM
@Adám is there a way to import exported const variables with ⎕NA?
 
Adám
Adám
@nathanrogers ⎕NULL is implemented as a pointer to a constant "namespace". ⍬ isn't "null"y at all; it is just another array. Don't confuse it with the mathematical null-set symbol.
@nathanrogers I suppose that the integer 0, when interpreted as a pointer becomes a null pointer, so that sounds right.
@nathanrogers I have no clue what that even means ¯\_⁽⍨⁾_/¯ but I'll ask JD to have a look.
 
nathan rogers
nathan rogers
ok
basically there are a whole host of bit flags in my library, and they're consts with NAMES_LIKE_THIS that are used throughout applications using this library
they're just constant values that cannot be redefined
not a function
@Adám it would seem that the names I'm interested in are coming from a .h file not the dll :(
 
 
2 hours later…
nathan rogers
nathan rogers
2:30 AM
is there an equivalent to C's hex format in APL? ex: 0x0124397
 
nathan rogers
nathan rogers
2:40 AM
@Adám the above link is the code I'm working with. The only dependency is GLFW3 dll which can be obtained here:
https://www.glfw.org/
There is a bug that I can't quite figure. It could be 32 bit, so I'll try using the 32 bit APL, but the window opens, the color buffer is cleared, and the window can close upon clicking x
the bug is in the glBegin and glEnd where nothing happens. For some reason 0.0 doesn't stay as a value in the editor, it always reverts to 0. (when using v2f, I try to put 0.0, but the editor changes it to 0)
otherwise, the only thing I can figure is that the CBB (GL_COLOR_BUFFER_BIT) or the GLT (GL_TRIANGLES) isn't correct? CBB works because the screen changes from white to black, but perhaps the GLT isn't correct?
according to this, GLT is 0x0004 which is 4, so I don't know why that would be a problem.
If you could ask anyone familiar with ⎕NA and C to take a look, that'd be a great help
This is taken straight from the documentation and my working C++ code
The init function is successful, and the window pointer has a value. I'm not super familiar with the tools in Dyalog to figure out how to do any deeper debugging than printing out stuff that has vlaues
should look like this:
https://imgur.com/UIJytoQ
 
Jonah
Jonah
3:23 AM
@Adám Thanks for looking into that for me. Here's another for you, but one that you can probably answer as an APL guy. Consider part 2 of last night's advent of code:
It has a very simple standard procedural solution using a hash and a while loop
which executes almost instantly. But I found quite it quite hard to find a good tacit solution in J. I came up with this, which works, but it uses tacit do.. while and takes 30s to complete:
It seems to be one of those rare problems for which J/APL aren't well suited. These are typically looping problems where the size of input to be processed is dynmically determined -- problems requiring hash structures for good performance also seem not to be a great fit for J. Of course, the problem may be my own lack of expertise which is why I ask...
cc/ @Bubbler
 
nathan rogers
nathan rogers
4:00 AM
@Adám I've eliminated the 64 32-bit and the 0.0 vs 0 problems. 0.01 doesn't do anything either, and I'm already using the 64 bit opengl dll. Now I'm really ou tof ideas.
 
nathan rogers
nathan rogers
4:15 AM
Unless it has something to do with the internal representation of hex numbers
I found hexf in dyalogs docs, but it crashed the program
 
H.PWiz
H.PWiz
@nathanrogers Like big vs little endian? If so, I would personally have no clue what to do
 
nathan rogers
nathan rogers
4:39 AM
That might be a path to a solution. I'll check it out tomorrow
 
 
4 hours later…
Cows quack
Cows quack
9:07 AM
@Jonah "where the size of input to be processed is dynmically determined" not necessarily in this case :)
 
Cows quack
Cows quack
10:04 AM
for instance this (spoiler) tio.run/… finishes almost instantly
(neat idea of using the ^:_ on the outside, I borrowed that in ^)
 
 
5 hours later…
Jonah
Jonah
3:16 PM
@Cowsquack Love it, that is a very clever insight. Of course, there are problems where no such analogous trick exists, and you really do need to store an ever-growing list in a hash... so i'm still curious what J experts say about those cases...
 
 
2 hours later…
Jonah
Jonah
5:28 PM
Also, as much as i love your solution, i think it's hard to argue that it's simpler than something like this boring procedural loop: bit.ly/2E8mZ8F. And usually it's the other way around: ie, the J framing and solution of a problem actually simplifies it conceptually, as well as making it shorter.
 
 
4 hours later…
nathan rogers
nathan rogers
9:39 PM
@Adám @H.PWiz I found the above documentation containing "Passing floating-point values using ⎕NA"
I don't think the endianness is an issue then.
Attempting to use D in place of F for the v2f function crashed dyalog
F Float The value is interpreted as an IEEE 754-2008 binary64 floating point number
And apparently floats don't have the means of specifying width?
C data types
In the C programming language, data types are declarations for memory locations or variables that determine the characteristics of the data that may be stored and the methods (operations) of processing that are permitted involving them. The C language provides basic arithmetic types, such as integer and real number types, and syntax to build array and compound types. Several headers in the C standard library contain definitions of support types, that have additional properties, such as providing storage with an exact size, independent of the implementation. == Basic types == The C langua...
But here, it looks like we might be back to 64 vs 32 bit problem. The float type in C is a 32 bit single precision floating point, but the double type is 64 bits, but then when I attempt to use D instead of F dyalog itself crashes
 
nathan rogers
nathan rogers
10:05 PM
@Adám I have downloaded the 32 bit v14, and swapped out with a 32 bit GLFW dll, still nothing
 

« first day (676 days earlier)      last day (1994 days later) »