Hey, I am trying to put together a basic reflection system, but
I've run into a problem. I'm not sure if this is a bug or not.
I am trying to store method information about a class. So
basically, I am using Traits to go through all members of the
class, and then trying to create delegates to
On Friday, 10 October 2014 at 17:43:13 UTC, Kapps wrote:
On Friday, 10 October 2014 at 17:00:01 UTC, bitwise wrote:
Hey, I am trying to put together a basic reflection system,
but I've run into a problem. I'm not sure if this is a bug or
not.
I am trying to store method information about a
I am trying to store a function pointer in a class in a generic
way(works with all member/non-member/global functions).
In the main() function below, there are two cases(A, B).
If case B is commented out, this code complies/runs fine.
Otherwise, I get these errors, and the compiler pointing
On Monday, 27 October 2014 at 16:08:26 UTC, Solomon E wrote:
It works after I added 'static' to the declaration of
'invoke()' (and import std.stdio, std.traits.)
I fiddled around with it for hours before I tried 'static'
there, because I've only been studying D for a week, so only
about half
this means that something gone wrong in the process.
'(__error)' is the
pseudotype for failed CTFE/instantiation.
But why did the instantiation fail? and more importantly, why did
it not have consistent behaviour between the two templates above?
what do you want to achieve
with second
quotes self
Here is a better example, showing that virtual function pointers
are available at compile time in C++. Essentially, I would expect
my D code to function similarly, but it won't compile.
class TestAddr {
public: virtual void test() { cout test endl; }
};
templatevoid
C++ compiler does some trickery behind the curtains. besides,
you
aren't supposed to make such hackish things easily in D. yet
you can:
There is nothing hackish in the above code. It's a non-type
template parameter and a member function pointer. If I was trying
to access the (implementation
besides, you can use CTFE to build wrapper code. Adam Ruppe
has that in
his jsvar.d, and i have that in my cong.d (cmdcon-ng) too.
I have actually found a work around as well, which was to wrap
the actual retrieval of the function address in a lambda, and
pass the lambda by template
On Tuesday, 28 October 2014 at 02:34:14 UTC, ketmar via
Digitalmars-d wrote:
On Tue, 28 Oct 2014 01:36:01 +
bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote:
I have actually found a work around as well, which was to wrap
the actual retrieval of the function address in a lambda
That being said, you only need to worry about any of this if
you want to support virtual methods and have it invoke the
actual overridden method, not the one you have saved through
reflection. (For example, if Bar : Foo overrides foo, and you
generated reflection info for Foo, it would call
I think I've got it figured out.
In my original example, I added the following line inside the
function-template, and the class-template:
pragma(msg, typeof(T).stringof);
in both cases, the (correct)result was a tuple of a function
(void())
But, when it came time to retrieve the address
The docs for template mixins do show mixins inside functions, so
is this a bug, or is there something else I'm doing wrong?
//**
module main;
import std.traits;
class ModInfo {
}
mixin template moduleInfo(alias MODULE) {
static const(ModInfo) __module_info =
On Friday, 28 November 2014 at 19:24:33 UTC, Daniel Kozak via
Digitalmars-d wrote:
Dne Fri, 28 Nov 2014 20:01:41 +0100 bitwise via Digitalmars-d
digitalmars-d@puremagic.com napsal(a):
The docs for template mixins do show mixins inside functions,
so is this a bug, or is there something else
Yes this will
I think I may not have explained myself correctly, which is a
mistake I often make in an effort to simplify the question =/
but, the assertion in the code below fails:
immutable class ModInfo {}
static moduleInfo(alias MODULE)() {
return new ModInfo();
}
static
void main() {
static m = getModuleInfo!(test);
static m2 = getModuleInfo!(test);
static m3 = getModuleInfo!(test);
assert(m == m2); // PASS
assert(m == m3); // PASS
}
correction:
static m = getModuleInfo!(test);
static m2 = getModuleInfo!(test);
auto
In the following program, the output does not contain
SomeClass. Is this a bug?
module main;
import std.stdio;
mixin template Test()
{
class SomeClass {
int n = 123;
}
}
mixin Test;
void main() {
auto sc = new SomeClass;
writeln(sc.n);
On Sunday, 30 November 2014 at 08:00:20 UTC, Daniel Kozak wrote:
On Sunday, 30 November 2014 at 02:10:13 UTC, bitwise wrote:
In the following program, the output does not contain
SomeClass. Is this a bug?
Maybe yes, as a workaround this works:
module main;
import std.stdio;
template Test()
https://issues.dlang.org/show_bug.cgi?id=13800
But I just try to say you can omit mixin word in template
declaration. Because it doesn't have any effect.
mixin != mixin template != template
On Monday, 1 December 2014 at 07:28:28 UTC, Daniel Kozák via
Digitalmars-d wrote:
V Mon, 01 Dec 2014 00:07:10 +
bitwise via Digitalmars-d digitalmars-d@puremagic.com napsáno:
But I just try to say you can omit mixin word in template
declaration. Because it doesn't have any effect
Hi,
I have a mixin, which can mix a class into any module. At
compile time, I will know the name of the class, it's base class,
and that it is at global scope in some module.
Is there any way to find this class from a different module at
compile time?
Thanks
On Saturday, 6 December 2014 at 20:22:13 UTC, bitwise wrote:
Hi,
I have a mixin, which can mix a class into any module. At
compile time, I will know the name of the class, it's base
class, and that it is at global scope in some module.
Is there any way to find this class from a different
why do you need that?
I've made a reflection library which creates metadata on a
per-module basis.
usage would be like this:
[code]
module test;
// classes, methods, etc..
mixin(reflect!test); // generates reflection here so private
members are accessible
[/code]
-or-
[code]
module
why don't create a dummy module which only keeps list of all
known
objects, and create `shared static this ()` constructors which
will
just register everything in that module?
I am actually doing this already, but this only solves for
finding information at runtime.
One or more of these
On Sunday, 7 December 2014 at 06:25:48 UTC, ketmar via
Digitalmars-d wrote:
On Sun, 07 Dec 2014 05:42:31 +
bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote:
what you actually want is some cross-module compile-time data
storage.
this is impossible to implement. at least to make
if you want to allow external pragmas that allows poking
private module
data... well, just make everything in that module public, you
just
killed the whole protection thing. ;-)
This is what I mean, but I don't think it would 'kill' anything.
It's not like I'm suggesting that cast(public) be
While I hear a lot of experienced programmers take this point of
view, I still don't really understand or agree with it. I believe
a good language should facilitate good design, but I don't think
it should force it. I imagine this type of principal may simplify
code review for large projects,
FWIW, I picked hp D ~2 months ago, and my first project was a
reflection library, so I've had a chance to deal with most of the
language features at least once so far. The naming and presence
of legacy C++ was a little strange, but I would leave it at that.
What was by FAR the most
D devs are quite willing to improve error messages, they have
improved many of them.
I'm not trying to call anyone lazy ;) Sometimes though, the bugs
I imagine I would submit seem like they would lead to a wild
goose chase more than a solution.
Don't forget to mention DustMite.
I'll
so let intellisense-like systems do the guesswork. i don't
trust a
compiler that tries to guess what i mean instead of reporting
the error
and stop right there. i.e. i once tried PL/1 compiler which was
able to
guess what lone `IF` means. and now i don't want the compiler
to
do *ANY*
@manu
I'm a little confused.. Looking through your Fuji/Source/Drivers
folder, I see folders for IPhone and Android, among others...
does your engine actually run on these platforms?
I was under the impression that D could not compile to those
targets yet.
Actually, iOS and Android both have x86 emulators don't they?
You'll notice that the engine code is not D code...
Hmm... Indeed.. I just assumed when I saw Walter get all excited
;)
D will work on most of those platforms just fine if you abandon
the GC and exception handler.
Unfortunately, I don't know D-compiler/runtime well enough to
actually
On Tuesday, 16 December 2014 at 15:39:06 UTC, bitwise wrote:
You'll notice that the engine code is not D code...
Hmm... Indeed.. I just assumed when I saw Walter get all
excited ;)
D will work on most of those platforms just fine if you
abandon the GC and exception handler.
On Wednesday, 17 December 2014 at 16:18:19 UTC, CraigDillabaugh
wrote:
On Wednesday, 17 December 2014 at 01:28:55 UTC, Manu via
Digitalmars-d wrote:
The average gamer today is aged 30.
I for one haven't gotten any money from my mum for games
recently...
Christmas is right around the corner
I'm curious if there are any upgrades coming in the near future.
As a D-Newbie, I find myself combing these forums regularly to
try and get up to speed on what's going on, but there are several
things making it difficult.
-I have a valid email address in the box up there^, but I don't
Guess it's not so great when your OS doesn't have a package
manager that uses signed packages though.
: )
Welll Some people seem to love the terminal, but in all
honesty, if it wasnt' for Mono-D, I would not have taken the time
to learn D.
Welll Some people seem to love the terminal, but in all
honesty, if it wasnt' for Mono-D, I would not have taken the
time to learn D.
Not to say that I'm not glad I did learn D, but I don't imagine
anyone wanting to learn D would just take it on full throttle
without first experimenting
Filters or some form of moderation would also be nice.
Overall I find the site kind of tough on my eyes, I use a
stylish theme to help.
https://userstyles.org/styles/65395/dlang-org-dark-theme
I am getting more and more weary of downloading software these
days unless it's very well known. I almost got infected by
malware yesterday by
The forum is a front-end to a newsgroup. A news reader or email
client might have the features you want (including custom
styling to your preferences).
I thought that this was the case, but I prefer using a web
interface.
I appreciate having the ability to visit these forums on any
Userstyles is a site for Stylish themes, it's an open source
extension for most browsers released under GPLv3.
So is Filezilla...but would you care to download a copy? ;)
http://sourceforge.net/projects/filezilla/files/FileZilla_Client/3.10.0/
On Sunday, 11 January 2015 at 05:28:57 UTC, Joakim wrote:
On Saturday, 10 January 2015 at 22:29:42 UTC, bitwise wrote:
I'm curious if there are any upgrades coming in the near
future.
As a D-Newbie, I find myself combing these forums regularly to
try and get up to speed on what's going on,
Do *you know what progress is?
http://arsdnet.net/this-week-in-d/mar-22.html
Author say's it's been a slow week, but you can watch these to
get a better feel for the pace of D.
Seriously, do you believe that just because Qt, Xcode, VS, etc
do not have such features that such features are
But first we need to finish off what support we damn well have
in druntime.
m_offTi for TypeInfo_Class currently is not being generated.
We also need some form of RTInfo for modules. Not just for
symbols. This alone will open up quite a few doors!
In the time for std.reflection convo, it
This definitely should be a library solution.
In terms of what Andre was suggesting, I think my implementation
is 90% of the way there, so if the will was there to add
something like std.reflection to phobos, it wouldn't be much of a
leap.
But it seems silly, to not use code in druntime.
https://github.com/D-Programming-Language/druntime/pull/775
https://github.com/D-Programming-Language/dmd/pull/2271
I've read over the comments of the above two pull-requests, and
I'm confused about what is trying to be achieved.
A ModuleInfo for each module already exists and is available at
On Linux and OSX, the build for just the unittest library would
generate an over 40MB executable. On Windows with Optlink
though, it was only 4MB, so perhaps there are optimizations
that could be made to reduce the size on OSX / Linux.
This sounds like a bug.. if it CAN be done with an
I came across this post a while back and decided to implement it:
http://forum.dlang.org/thread/juf7sk$16rl$1...@digitalmars.com
My implementation:
https://github.com/bitwise-github/D-Reflection
The above conversation seemed to stop abruptly, so I went on to
assume that no one chose to
https://github.com/D-Programming-Language/dlang.org/pull/946
After looking at DIP74, it seems that there is no way to create a
weak reference to a ref counted object, but is not explicitly
stated. Has this idea been considered at all?
On Wednesday, 4 March 2015 at 18:59:54 UTC, Andrei Alexandrescu
wrote:
On 3/4/15 10:48 AM, bitwise wrote:
After looking at DIP74, it seems that there is no way to
create a weak
reference to a ref counted object, but is not explicitly
stated. Has
this idea been considered at all?
DIP74 aims
On Sunday, 22 February 2015 at 03:35:28 UTC, ketmar wrote:
On Sat, 21 Feb 2015 21:19:32 +, bitwise wrote:
Input on this would be appreciated.
it seems to me that you can abuse delegates for this (i mean
the
underlying fat pointer). resumable function can create
closure (i think
all the
On Tuesday, 24 February 2015 at 00:48:34 UTC, ketmar wrote:
On Mon, 23 Feb 2015 23:10:28 +, bitwise wrote:
you still thinking in terms of generators. Generator is a
high-level construct, resumable routine is a low-level
construct. latter is used to build the former.
I think you're
ahem. seems that you are right, and i outsmarted myself yet
again. seems
that my head is too small to keep three different task unmessed
(forum
discussion, plus two of my projects).
sorry.
If it's any consolation, I did accidentally use a C++ constructor
in my first example..
I better
@ketmar
You know you may be kinda right about reusability though...
I am not as familiar with await as I am with coroutines, but I
think the principal is similar. The Visual Studio team seems to
have chosen to tackle stackless resumable routines and await at
the same time, so there may be
you don't need to. if you really need to do that, you're doing
something
This makes no sense to me. A usage example may be helpful.
resumable functions are not iterators. it's a slightly
perversed flow
control method. iteration/generation is one of the use cases.
So how do you explain
Just out of curiosity, is anyone planning to implement this?
As for why it's not already implemented, is it because of lack of
interest, or prohibitive reasons?
On Friday, 24 October 2014 at 10:33:40 UTC, Martin Nowak wrote:
This is so much better than Fibers.
http://youtu.be/KUhSjfSbINE
They are waiting for your pull request :o)
Welll... I would like to try, but there is good reason behind the
noncommital phrasing of my question :)
I experimented with stackful coroutines in C++, but I think
stackless resumable functions will be more difficult. I assume I
can harvest most
It's an easy way for people to get started with D, and IMO,
Mono-D, along with Visual D should be listed right at the bottom
of the Getting Started page.
http://dlang.org/getstarted.html
On Friday, 27 March 2015 at 20:41:17 UTC, weaselcat wrote:
On Friday, 27 March 2015 at 20:40:25 UTC, bitwise wrote:
Just curious why Mono-D isn't included on the Downloads page.
AFAIK mono-d is meant to be installed from the plugin section
of monodevelop, isn't it?
True, but I think it
Just curious why Mono-D isn't included on the Downloads page.
On Friday, 27 March 2015 at 20:56:41 UTC, bitwise wrote:
It's an easy way for people to get started with D, and IMO,
Mono-D, along with Visual D should be listed right at the
bottom of the Getting Started page.
http://dlang.org/getstarted.html
would it be accepted if I did a pull request
This is what I imagine. I know it can be done, that is not the
issue. This is all standard programming stuff. That is not the
point. The point is, to discuss ideas freely so the best
solution(Which is usually a combination of all relevant inputs).
1. Get up in the morning
2. Turn on computer.
Currently in object.d in druntime there's
a template, RTInfo, declared something
like this:
[snip]
Thanks for the breakdown! Those pull requests make a lot more
sense when read in the proper context ;)
The main reason for implementing RTInfo
for modules is to implement reflection.
With the
On Mon, 13 Apr 2015 08:57:26 -0400, rcorre r...@rcorre.net wrote:
For me, having a solid reflection library like this is one of the most
important improvements D can make right now.
At this point, I've kinda hit a wall.
Generating a hierarchical/object-oriented representation of the type
On Sat, 25 Apr 2015 09:50:46 -0400, Daniel Murphy
yebbliesnos...@gmail.com wrote:
bitwise wrote in message
news:op.xxishfi24sdys0@nicolass-macbook-pro.local...
I have a class with callbacks that can be overridden, which are
inherited from an extern(C++) interface. The callbacks are
On Sat, 25 Apr 2015 09:50:46 -0400, Daniel Murphy
yebbliesnos...@gmail.com wrote:
bitwise wrote in message
news:op.xxishfi24sdys0@nicolass-macbook-pro.local...
I have a class with callbacks that can be overridden, which are
inherited from an extern(C++) interface. The callbacks are
I have a class with callbacks that can be overridden, which are inherited
from an extern(C++) interface. The callbacks are called from C++ code. Is
there any chance that the linkage will be inferred in the future?
To be clear, couldn't the extern(C++) just be inferred in the class
'MyTest'
On Thursday, 23 April 2015 at 00:47:30 UTC, bitwise wrote:
I have a class with callbacks that can be overridden, which are
inherited from an extern(C++) interface. The callbacks are
called from C++ code. Is there any chance that the linkage will
be inferred in the future?
To be clear,
On Mon, 27 Apr 2015 22:26:56 -0400, Andre Tampubolon an...@lc.vlsm.org
wrote:
I decided to wipe my dmd directory (too messy), and replaced it with the
latest one
(http://downloads.dlang.org/releases/2.x/2.067.1/dmd.2.067.1.windows.zip).
After that, I adjusted the bin directory, and sc.ini as
The D Tales
On Sat, 09 May 2015 21:09:33 -0400, Ali Çehreli acehr...@yahoo.com wrote:
On 05/09/2015 07:01 AM, bitwise wrote:
./main.d
./pack/foo.d
./pack/sub/bar.d
dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H
This dumps all the *.di files into the output directory ignoring the
directory structure.
On Sat, 09 May 2015 21:31:20 -0400, Ali Çehreli acehr...@yahoo.com wrote:
On 05/09/2015 06:18 PM, bitwise wrote:
I'm not sure I understand what you mean, but my point is, that as is,
this feature of DMD is broken.
Arguably broken but compared to other tools it behaves in the same way.
On Sat, 09 May 2015 10:01:25 -0400, bitwise bitwise@gmail.com wrote:
./main.d
./pack/foo.d
./pack/sub/bar.d
dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H
This dumps all the *.di files into the output directory ignoring the
directory structure.
Is there some rational for it being
On Sunday, 10 May 2015 at 01:00:31 UTC, bitwise wrote:
Is there really no way to preserve the directory structure when
creating .di files?
Bit
Why hello, Bitwise! I believe the '-op' flag is what you're
looking for!
Bitwiser
On Sun, 10 May 2015 04:20:45 -0400, Marco Leise marco.le...@gmx.de wrote:
I agree, D modules are hierarchical and sometimes share the
same base name. Header files are very important to short
circuit the transitive import chain. We've already seen it in
Phobos. Many modules ends up pulling in
./main.d
./pack/foo.d
./pack/sub/bar.d
dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H
This dumps all the *.di files into the output directory ignoring the
directory structure.
Is there some rational for it being this way?
Wouldn't it be much more useful if directories were preserved?
On Thu, 14 May 2015 02:56:46 -0400, Namespace rswhi...@gmail.com wrote:
On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote:
Side note: DIP36 seems to be missing the table with the authors,
status, etc.
Bit
Huh, DIP36? DIP36 was rejected, but the authors (me and Dicebot) are
On Thu, 14 May 2015 13:15:34 -0400, Namespace rswhi...@gmail.com wrote:
On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote:
If it were up to me, I would say:
'scope' should be removed as a storage class,
'ref' should be left as is, and
'in' should adopt the behavior of 'ref' post DIP25
On Tue, 12 May 2015 08:54:15 -0400, Namespace rswhi...@gmail.com wrote:
As far as I know, the problem (or at least one of the biggest problems)
for rvalue references was that they could escape. Since DIP25 is
approved and already implemented this problem should be solved. Would it
be
On Tue, 12 May 2015 08:54:15 -0400, Namespace rswhi...@gmail.com wrote:
As far as I know, the problem (or at least one of the biggest problems)
for rvalue references was that they could escape. Since DIP25 is
approved and already implemented this problem should be solved. Would it
be
On Thu, 14 May 2015 16:12:36 -0400, Namespace rswhi...@gmail.com wrote:
Don't ask me, I'm just a little light here.
But I think it's because 'in' means 'const scope' and as you said, scope
is out. ;)
Which means 'in' is available! ;)
Bit
On Tue, 14 Apr 2015 04:16:16 -0400, Jacob Carlborg d...@me.com wrote:
On 2015-04-14 07:03, bitwise wrote:
You may want to look at Orange.
https://github.com/jacob-carlborg/orange
The API is clean, and non-invasive. The only downside for me, is that in
order to serialize a class by a base
On Wed, 15 Apr 2015 05:31:24 -0400, Jacob Carlborg d...@me.com wrote:
It needs to be possible to set and get a value of an instance variable
based on it's name, through runtime reflection. It also needs to bypass
protection, i.e. private.
Right now, this is the def:
/**
* Array of
On Wed, 15 Apr 2015 11:26:48 -0400, bitwise bitwise@gmail.com wrote:
But AFAIK, this is NOT ok in C++ because of the way inheritance works..
is this safe in D?
To clarify, I'm talking about doing doing things by Object pointer or void
pointer, which seems to work fine:
class Test {
On Wed, 15 Apr 2015 15:48:28 -0400, Jacob Carlborg d...@me.com wrote:
On 2015-04-15 17:26, bitwise wrote:
Right now, this is the def:
/**
* Array of pairs giving the offset and type information for each
* member in an aggregate.
*/
struct OffsetTypeInfo
{
size_t offset;///
One more thing.
I had to add a virtual destructor to A to get this to work:
class A {
public: int a; virtual ~A(){}
};
//
A *d2 = (A*)d;
cout boolalpha (typeid(*d2) == typeid(D)) endl;
C *d3 = (C*)d;
cout boolalpha (typeid(*d3) == typeid(D)) endl;
Output is now:
true
false
On Thu, 16 Apr 2015 02:22:25 -0400, Jacob Carlborg d...@me.com wrote:
In D I would assume this would eventually be possible:
class Foo { int a; }
class Bar : Foo { int b; }
Foo f = new Bar;
auto offset = typeid(f).getMemeber(b).offset;
auto ptr = cast(int*)(cast(void*)f + offset);
*ptr = 4;
On Fri, 17 Apr 2015 05:30:04 -0400, Jacob Carlborg d...@me.com wrote:
On 2015-04-17 01:25, bitwise wrote:
Ok, that sounds right. D has no multiple or virtual inheritance, so I
guess things should be fine. C# is the same way(single inheritance,
interfaces) which is likely designed to avoid
On Sun, 12 Apr 2015 18:01:59 -0400, Barry Smith barry.of.sm...@gmail.com
wrote:
It's simple, but clean. Somewhat similar to the old one. Hope you like
it.
http://s2.postimg.org/m6qcfemhl/dlang.png
Email me at barry.of.sm...@gmail.com if you want the SVG version.
D needs merit, not
On Friday, 3 April 2015 at 17:58:27 UTC, Dicebot wrote:
On Friday, 3 April 2015 at 17:51:33 UTC, Andrei Alexandrescu
wrote:
Thanks Adam and Steve. Guess I should have asked this in the
learn forum :o). -- Andrei
Yeah, I have totally expected some revolutionary proposal for
RTTI improvement
It most certainly is.
I've continued to dig and try to reason about the history behind
this problem.
This code has actually been around since D1, but was never
completed:
https://github.com/D-Programming-Language/dmd/blob/master/src/dsymbol.c#L1237
I think finishing up getMembers() rather
I'm trying to add some compile-time function generation to dmd,
but wasn't sure exactly how to click all the little legos
together.
Is there any documentation or reference for the DMD AST? Or maybe
some examples somewhere of what an AST may look like for a given
function?
As a last resort,
On Saturday, 4 April 2015 at 08:14:13 UTC, Dan Olson wrote:
Seemed worth mentioning before I snooze. My daughter and I
just got a
little touch app running on an iPad using D and Allegro 5.1.
Really
nothing major, but it does work. Just dragging some text
around the
screen with my finger
On Thursday, 2 April 2015 at 06:57:25 UTC, Jacob Carlborg wrote:
On 2015-04-02 02:28, bitwise wrote:
If I'm understanding correctly, doing it this way is to avoid
making
changes to the compiler, right?
I don't understand this decision because it seems that most of
the
needed infrastructure
I love the idea of it.
But first we need to finish off what support we damn well have
in druntime.
m_offTi for TypeInfo_Class currently is not being generated.
We also need some form of RTInfo for modules. Not just for
symbols. This alone will open up quite a few doors!
Ok, I'm starting to
I'm pretty sure this function here is converting the typeinfo to
a linked list of data that gets outputted to the object file:
..
Scratch that, I think this is what I'm looking for:
https://github.com/D-Programming-Language/dmd/blob/master/src/toobj.c#L308
One more question:
Does anyone know why TypeInfo_class.getMembers() was removed? [1]
I found an old post saying that it never worked and returned an
empty array, so that is most likely the answer, but although
getMembers was removed, Walter seems to have left behind the
classes MemberInfo,
On Wednesday, 20 May 2015 at 18:53:30 UTC, Jacob Carlborg wrote:
On 2015-05-20 16:44, bitwise wrote:
I tried using a shared library for OSX yesterday. I opened it
with
dlopen, retrieved my extern(C) function, and called it. All
was well,
and it seemed to work(wrote to the console with
1 - 100 of 640 matches
Mail list logo
