On 2015-03-11 08:47, Vladimir Panteleev wrote:
On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:
On 3/11/15 12:19 AM, Vladimir Panteleev wrote:
What happens if a regression occurs in Vibe just before a D release? Do
we block the release for the sake of Vibe?
Yes.
On 2015-03-24 19:40, Adam D. Ruppe wrote:
I forgot to post it online this Sunday.
If you just forgot to post it I would recommend automating the process
or add a weekly reminder to your calendar.
--
/Jacob Carlborg
On 2015-03-25 13:14, wobbles wrote:
http://dlang.org/download.html
Each of the download links are semi-overlaid on each other.
Tested on the latest Chrome and Firefox on Ubuntu 14.04.
With a new release out, I suspect these pages will be used a lot!
Looks fine to me. Although this page [1]
On 2015-03-25 20:49, Walter Bright wrote:
Should be corrected now.
Yes, thanks. Do you have a commit to reference when I close the
corresponding bug report [1]?
[1] https://issues.dlang.org/show_bug.cgi?id=14322
--
/Jacob Carlborg
On 2015-03-25 16:36, Andrei Alexandrescu wrote:
Apparently not - the download page is a mess:
http://downloads.dlang.org/releases/2.x/2.067.0/ -- Andrei
The left side is fixed now [1].
[1] http://forum.dlang.org/post/mev3gi$j11$1...@digitalmars.com
--
/Jacob Carlborg
On 2015-03-25 11:11, extrawurst wrote:
the changelog on our main page links the releases to the download - this
does not work for 2.065 anymore.
clicking on 2.065 links to:
http://downloads.dlang.org/releases/2.x/2.065
which is a 404 right now. that looks kinda unprofessional
Hmm, basically
On 2015-03-25 16:37, Andrei Alexandrescu wrote:
Also why the overly complicated link?
http://downloads.dlang.org/releases/2.x/2.067.0/ should really be
http://downloads.dlang.org/2.067.0/
I completely agree. What's really annoying is that betas are under
pre-releases. Personally I would dump
On 2015-03-30 04:09, Rikki Cattermole wrote:
We also need some form of RTInfo for modules.
I made a pull request for that but unfortunately it hasn't been accepted
yet. The reason seems to be that we need to come up with a way to do
custom RTInfo without modifying druntime, that can also be
On 2015-03-30 09:06, Rikki Cattermole wrote:
You, me and Walter should have a chat then. I could pretty easily come
up with a way to add data into RTInfo.
I've already come up with a way, any template with the @rtInfo UDA is
treated the same way as RTInfo is now. The problem is then how to
On 2015-03-30 18:09, Martin Krejcirik wrote:
Here is one example:
Orange d5b2e0127c67f50bd885ee43a7dd61dd418b1661
https://github.com/jacob-carlborg/orange.git
make
2.065.0
real0m9.028s
user0m7.972s
sys 0m0.940s
2.066.1
real0m10.796s
user0m9.629s
sys 0m1.056s
2.067.0
On 2015-03-30 23:31, bitwise wrote:
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.
Currently in object.d in
On 2015-03-31 04:18, Andrei Alexandrescu wrote:
Thanks for this initiative. It would be indeed awesome if this got a bit
more attention. Once we get the portal fleshed out, we can promote the
link to the homepage.
One note about Walter's older C/C++ transition articles. They have good
On 2015-03-30 23:52, Andrei Alexandrescu wrote:
We're having a strong need for named unittests at Facebook for multiple
reasons.
1. We have sophisticated tooling that verifies whether unittests are
flaky. The automated monitor (for e.g. C++) figures whether a given
unittest fails several times
On 2015-03-31 01:40, w0rp wrote:
Why add extra syntax for what you can already do pretty nicely with a
library?
It would be nice if D could support a generic syntax for trailing
delegates, i.e.
benchmarks
{
}
Would be lowered to:
benchmarks({
});
Then it can be implemented as a
On 2015-03-31 01:15, Mathias Lang via Digitalmars-d wrote:
I'd rather see DMD automatically pass the expression that triggered the
error (as it is done in C) to replace this useless Unittest failure
that forces me to look through the code.
D has the advantage that it catches most errors at CT.
On 2015-03-31 02:46, Andrei Alexandrescu wrote:
Often you need the context.
That should be printed as well [1]
[1] http://thejqr.com/2009/02/06/textmate-rspec-and-dot-spec-party.html
--
/Jacob Carlborg
On 2015-03-31 08:10, Andrei Alexandrescu wrote:
The thing here is you're not forced to build both the unittest version
and the deployed version. It's an opt-in thing. The problem currently is
we format error messages badly so we make Good Things difficult. -- Andrei
It's not difficult. I've
On 2015-03-31 02:49, Rikki Cattermole wrote:
While we are at it, how about improving CTFE to be fully JIT'd and
support calling external code? That way it is only a small leap to add
unittests to be CTFE'd.
It's already possible to run unit tests during compile time as CTFE [1].
[1]
On 2015-03-31 01:28, w0rp wrote:
I sometimes think DMD's memory should be... garbage collected. I used
the forbidden phrase!
Doesn't DMD already have a GC that is disabled?
--
/Jacob Carlborg
On 2015-03-31 19:05, Jonathan wrote:
Well, I don't consider benchmarks a kind of unit test. So maybe just
this:
It depends on how you look at it. I know Xcode has support for some kind
of unit test benchmark. You can assign a upper value to a benchmark and
if that value is exceed the
On 2015-03-31 22:01, Andrei Alexandrescu wrote:
I made a few editorial passes, no major changes. I think there's still a
fly in the ointment. The resolution algorithm goes:
1. If xyz is a symbol (member, method, enum etc) defined inside
typeof(obj) then lookup is done.
2. Otherwise, if xyz is
On 2015-03-31 23:12, Atila Neves wrote:
I actually thought about the whole it should fail to build if any of
the unit tests fail idea 2 or 3 weeks ago, so this sounds good.
WRT to the error messages and their recognition by text editors, a
_massive_ improvement would be compiler-assisted
On 2015-03-31 23:08, Idan Arye wrote:
Limiting unittest names to legal identifiers will save a lot of headache
when we set our tools to actually use these names. Matching a legal
identifier in a text stream is much easier than matching an arbitrary
unicode string, even if that string is
On 2015-03-31 11:08, Johannes Pfau wrote:
But here's the problem:
1) The compile time approach requires some kind
of explicit registration of the unittests. At least one mixin per
module.
2) This mixin will usually provide a module constructor. But
using module constructors will
On 2015-04-01 07:00, H. S. Teoh via Digitalmars-d wrote:
On Wed, Apr 01, 2015 at 04:28:43AM +0200, Martin Nowak via Digitalmars-d wrote:
The lookup order for the config file should be changed to the following.
- next to dmd binary (highest precedence so that I can have multiple
installations)
On 2015-03-31 23:14, Idan Arye wrote:
Building by unittest name! Imagine - instead of placing temporary code
in `main` to develop a new feature or fix a bug, you put in a named
unittest and tell your IDE/build-system to only build that unittest(and
whatever code needed for it to run). You
On 2015-04-01 00:02, Idan Arye wrote:
I think you and I work under different assumptions of the goals for this
feature. If we only want unittest names to be something that can be
printed when the unittest runner runs the unittests, than a UDA with a
string is indeed preferable. If we want
On 2015-03-31 15:31, Dicebot wrote:
Most powerful solution would be to simply put attributes for unittest
blocks in runtime information for tests (using RTTI it should be
possible to define such variadic structure in similar manner as D-style
variadic function arguments).
I think the most
I'm currently updating the TextMate D bundle for D2. I have a couple of
questions for how to highlighting some specific code or how other
editors/IDE's highlight them.
* this in constructor
this () {}
In TextMate functions/methods are highlighted, should this be
highlighted as a keyword or
On 2015-03-26 12:23, Andrej Mitrovic via Digitalmars-d wrote:
One idea I'd like to see is to enhance scope(failure) to allow it to
catch a specific type of exception which would allow us to e.g. log
the exception message and potentially re-throw the exception. All of
this without having to nest
On 2015-03-27 13:33, Chris wrote:
Am using Textadept, the highlighting is as follows:
highlighted as keyword:
this()
Why is this highlighted as a keyword? I was more leaning to highlight it
as a method. What about the parameter in a copy constructor?
__traits
What about the
On 2015-03-27 15:03, Chris wrote:
Well, it _is_ a keyword. You cannot write a function called this, nor
can you use it as a variable name. So yes, it's a keyword = reserved.
It depends on how you see it. It's also a special method that just
happens to use a keyword as its name. It doesn't
On Tuesday, 31 March 2015 at 15:00:28 UTC, Andrei Alexandrescu
wrote:
Problem is doing that for all editors does not scale. -- Andrei
It's not like the error messages used by DMD are in a
standardized format. So hopefully the editors already recognize
this format. BTW, what about
On 2015-03-31 12:48, Laeeth Isharc wrote:
Often one doesn't know what one wants to write till one starts. I guess
the focus will be different coming from Ruby than coming from Basic,
because people think in different ways and tend to be solving different
sorts of problems - so I should think
On 2015-03-31 16:55, Meta wrote:
Aren't unittest blocks just special functions? If that's the case, there
should be no problem being able to give them names. It seems to me that
it would entail the lifting of a restriction rather than a real language
change.
Before:
unittest
{
assert(1 ==
On 2015-03-31 10:16, Andy Smith wrote:
Ah - didn't test for your specific example...
Need..
(add-to-list 'compilation-error-regexp-alist
'(^core\.exception.AssertError@\\(.*\\)(\\([0-9]+\\)).*
1 2 ) )
as well not sure how many variants of these there are but if
On 2015-03-31 20:26, Andrei Alexandrescu wrote:
The idea is to make a SMALL change on our side for a LARGE INSTANT
benefit for everyone. Sigh.
But does the editors handles the current format of the compile errors?
I don't see a reason.
Why wouldn't you want exceptions to be clickable as
On 2015-03-29 19:34, IgorStepanov wrote:
1. We should reject types which use opDispatch and alias this at the
same time.
Isn't there a well defined order these features apply in?
--
/Jacob Carlborg
On 2015-03-27 11:34, Jacob Carlborg wrote:
I'm currently updating the TextMate D bundle for D2. I have a couple of
questions for how to highlighting some specific code or how other
editors/IDE's highlight them.
What about #line?
--
/Jacob Carlborg
On 2015-03-23 10:47, bearophile wrote:
See:
https://issues.dlang.org/show_bug.cgi?id=7176
Exactly.
--
/Jacob Carlborg
On 2015-03-01 14:15, Daniel Murphy wrote:
Because a compiler recognized UDA is an additional complication for
something that is unlikely to be a problem for anyone. Do you have code
with methods named opAddRef? No? Me neither.
I don't agree. If those are the final names, no. But I do have
On 2015-02-27 19:38, Andrei Alexandrescu wrote:
I explicitly avoided the COM names in order to avoid potential confusion
and code breakage. People can easily add IUnknownAuto that does the
forwarding. -- Andrei
It's still a breaking change. See one of my other replies [1] for a
possible
On 2015-02-27 20:49, Taylor Hillegeist wrote:
I just think its a shame that all over the place people are compiling
code in different programming languages, and although all the .o files
are compatible with each other there isn't a standard cross language way
of defining a binding. But that
On 2015-02-26 22:50, Andrei Alexandrescu wrote:
http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and
discuss.
* What will happen if these methods are defined on a class that is
allocated on the GC? Is there any enforcement against this? Is there any
way an unsafe operation
On 2015-02-26 20:53, Taylor Hillegeist wrote:
So, In languages like .net they have dll's that contain not only
bytecode but also the necessary headers to make them usable in any .net
language. I was curious if this kind of thing has ever been attempted
for static libraries?
basically some type
On 2015-02-26 20:58, Walter Bright wrote:
It was a generational gc, I described earlier how it used page faults
instead of write barriers. I eventually removed the page fault system
because it was faster without it.
Instead you used?
--
/Jacob Carlborg
On 2015-02-26 21:45, Walter Bright wrote:
If you want some fun, take any system and fill up the disk drive to just
short of capacity. Now go about your work using the system.
You'll experience all kinds of delightful, erratic behavior, because
real world C code tends to ignore write failures
On 2015-02-26 22:50, Andrei Alexandrescu wrote:
http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and
discuss.
To me this looks like ARC (Automated Reference Counting). I know that
Walter has several complains about ARC, like he wrote in another thread [1]:
RC has further
On 2015-03-05 06:22, ketmar wrote:
or someone can try to resurrect it. it was very interesting effort, and
i'd like to see a Harmonia resurrected or something, ported to current
D version and with X11 backend.
sadly, i haven't enough time and motivation to do that.
Everyone is constantly
On 2015-03-05 08:38, Benjamin Thaut wrote:
I don't want to write new tests. I want to use the tests for phobos
which are already there. And I want to use them in a way, that if new
tests are added to phobos they are also tested against the dll version
of phobos. Yes integration tests would be
On 2015-03-03 18:49, Benjamin Thaut wrote:
I'm currently in the process of annotating all of phobos with export
and its quite cumbersome. To verify that I annoted all relevant
functions and types with export I would like to run the unitests against
the shared version of phobos. There is a
On 2015-03-03 23:29, Jonas Drewsen wrote:
On Tuesday, 3 March 2015 at 22:16:36 UTC, Freddy wrote:
I'm not much of a gui person,but what is the advantage of using QML
over D's import
statements(http://dlang.org/expression.html#ImportExpression) and CTFE.
No need to recompile (ie. have the
On 2015-02-27 21:04, Andrei Alexandrescu wrote:
I'm fine with breaking code of people who happen to use the names
opAddRef and opRelease. -- Andrei
I don't think so because it's so easy to making it a non-breaking
change, i.e. require a compiler recognized UDA to enable the functionality.
On 2015-02-28 10:41, Paolo Invernizzi wrote:
I agree, as, well, this is starting to look pretty grotesque...
The druntime/phobos 2.067 are breaking every piece of software out there
that relies on core.sync or concurrency.scheduler, vibe and tango included.
Add DWT to that list.
--
/Jacob
On 2015-02-28 06:57, deadalnix wrote:
I think this is justified to break the code here, but I share the
irritation in front of the inconsistency.
I don't think so because it's so easy to making it a non-breaking
change, i.e. require a compiler recognized UDA to enable the functionality.
--
On 2015-02-28 22:11, Andrei Alexandrescu wrote:
I've pushed for trello for a good while, it didn't catch up. -- Andrei
There's something called HuBoard [1], project management for Github
issues. I haven't used it myself but might be worth taking a look at.
Although it looks like you need
On 2015-02-28 18:06, Dicebot wrote:
C is pretty much a standard for cross-language ABI
You still need a way to define the bindings.
--
/Jacob Carlborg
On 2015-02-28 22:12, Andrei Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Is there any checking that the signatures of these methods matches the
ones in the base class if an implicit conversion to the base class is
made? Example:
On 2015-03-01 10:41, Paulo Pinto wrote:
What about having an UDA or a mixin for marking the types as RCO?
I already commented on that. Andrei said [1] he was fine with breaking
code for this feature. I don't understand why because it so easy to fix
with a compiler recognized UDA [2].
[1]
On 2015-03-01 13:41, Andrei Alexandrescu wrote:
We prefer opAddRef/opRelease to define an RCO, same as
empty/front/popFront define a range. -- Andrei
I don't see how a UDA would hurt.
--
/Jacob Carlborg
On 2015-02-22 03:23, Walter Bright wrote:
- RC has further performance and code bloat problems when used with
exception handling
Exceptions in Objective-C are basically like Errors in D. Should not be
caught and should terminate the applications.
Swift doesn't event have exceptions.
--
On 2015-02-22 10:48, Russel Winder via Digitalmars-d wrote:
If the D GC really is quite so bad, why hasn't a cabal formed to create
a new GC that is precise, fast and efficient?
It's like with everything else that hasn't been done. No one has cared
enough do to something about it.
There
On 2015-02-23 21:30, Walter Bright wrote:
Count me among those.
In Java, write barriers make sense because Java uses the GC for
everything. Pretty much every indirection is a GC reference.
This is not at all true with D code. But since the compiler can't know
that, it has to insert write
On 2015-02-22 21:48, Walter Bright wrote:
And I suspect that ARC is why they don't have exceptions.
Objective-C still has both ARC and exceptions. Although the
documentation [1] says that ARC is not exception safe by default, but it
does have a flag to enable it -fobjc-arc-exceptions.
[1]
On 2015-02-25 22:06, deadalnix wrote:
Here is something I've noticed going on various time, recently in the
memory management threads, but as to avoid an already heated debate,
I'll use enum types as an example.
We have a problem with the way enums are defined. If you have :
enum E { A, B, C }
On 2015-03-27 16:04, Dicebot wrote:
not at all. The fact it is reserved is already denoted by __, otherwise
it is just another vairable/symbol.
Doesn't this symbol also have special semantics?
--
/Jacob Carlborg
On 2015-03-23 20:17, klodkevin wrote:
What are your thoughts on this?
I didn't read the whole post but it looks like you've come up with
what's called Policy-based design [1]. The only difference is that you
combined several template parameters in one single parameter. I have
actually
On 2015-03-18 20:37, Walter Bright wrote:
Why use the tool if you're going to ignore it?
It's tremendously useful for reporting other issues. I can configure the
tool to not report the this issue but sometimes it's just easier to ignore.
--
/Jacob Carlborg
On 2015-03-28 01:01, Jesse Phillips wrote:
Statement [e.g. debug, return, function, with] (that needs fixed)
Not sure what you mean.
Probably should be Identifier for consistency [e.g. _arugments, __vptr,
_ctor]
I completely forgot about these. Should these be the same as __ctfe?
Which
On 2015-01-23 11:31, aldanor wrote:
Hi all, I've started redesigning dlang.org AGAIN (yea, I know...). The
front page is mostly done aside from a several responsiveness and
platform quirks, I will have the full landing page + a random sample
page from the docs this weekend. On the technical
On 2015-01-23 11:31, aldanor wrote:
Top-level-link: CHANGELOG
... is stale and rarely / randomly updated. This makes it look like
there is no development on the backend/phobos/runtime going on
whatsoever. There either needs to be an automated aggregator for github
pull requests (in which case
On 2015-01-29 22:47, Walter Bright wrote:
Ruby also has monkey patching, another misfeature.
It works great, have you actually used it? The entire Rails plugin
system is built around monkey patching. It's far more successful than
any D project.
--
/Jacob Carlborg
On 2015-01-29 22:02, ketmar wrote:
this never worked good. see deadalnix. or:
foo.bar
.zed
In Ruby .zed is not valid code, so in Ruby it means:
foo.bar.zed;
In D it, with my rules, it would mean:
foo.bar;
.zed;
In D you would need to write:
foo.bar.
zed
--
/Jacob Carlborg
On 2015-01-29 22:50, Walter Bright wrote:
error message clarity, recovery, and the correct identification of the
location of the error degrades substantially
I never had problems with the error messages in Ruby. But I do have had
problems with them in D. Example:
int a = 3
int b = 4;
On 2015-03-22 02:15, Andrei Alexandrescu wrote:
I've left a comment recently at
https://github.com/D-Programming-Language/phobos/pull/3087.
So what's the deal with that? Whenever a new tool leaves some trash, do
we chalk a circle on the pavement around it?
Not sure what you're complaining
On 2015-03-22 18:05, Martin Nowak wrote:
Sorry haven't read the whole thread.
I think there should be an option (even default on) to allow small
single line functions.
This can sometimes be fairly annoying. For example when writing range
adapters, see
On 2015-04-01 21:16, Dicebot wrote:
This is fixed by having smaller modules. If test for a single module
takes more than few blinks of an eye, something is wrong already.
For unit tests, yes. But there are other kinds of tests as well.
Integration, functional, user acceptance test and so on.
On 2015-04-01 20:49, Idan Arye wrote:
So now we just need a way to keep a line number unmodified when you add
lines above it...
I'm not sure what kind of tools you have in mind.
* Print a link which points back to a failing test, requires file and
line information
* Running a specific
On 2015-04-01 21:31, Dicebot wrote:
P.S. I hate all the Ruby testing facilities, hate with bloody passion.
The unit test framework in the Ruby standard library:
class FooTest
def test_foo_bar
assert 3 == 3
end
end
Looks likes most other testing frameworks out there to me.
--
/Jacob
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 is already built into ModuleInfo, and that it just
needs to be
On 2015-04-02 02:33, Martin Nowak wrote:
o current directory
o home directory
o exe directory (windows)
o directory off of argv0
o SYSCONFDIR (default=/etc/) (non-windows)
This sucks.
--
/Jacob Carlborg
On 2015-04-01 21:28, Ary Borenszweig wrote:
No, it's actually much simpler but less powerful. This is because the
language is not as dynamic as Ruby. But we'd like to keep things as
simple as possible.
Can't you implement that using macros?
But right now you get these things:
1. You can
On 2015-04-01 22:26, Walter Bright wrote:
The problem with inferring attributes on non-template functions is the
source must be available to the compiler. That's obviously true for
templates, but not so true for non-templates, where only the signature
is available.
In my experience with D,
On 2015-04-01 21:25, Dicebot wrote:
I 100% disagree. Having built-in unittest blocks have been a huge win
for the language and greatly improved quality of library ecosystem.
Value of standardization and availability is tremendous here.
Only problem is that development of the feature has
On 2015-04-01 21:18, Kapps wrote:
The only issue I have with the way unittests are done right now, is the
incredibly annoying requirement of having a main function and that main
gets called. It makes generic tooling and CI systems much more annoying,
as you have to try and guess whether you
On 2015-04-02 08:52, ketmar wrote:
executable code at module scope isn't really necessary, i believe.
I think so to have the same syntax.
--
/Jacob Carlborg
On 2015-04-02 08:59, ketmar wrote:
'cause inferring attributes requires running full semantic analysis on
the code, so each imported function *must* be fully processed.
Isn't this required anyway?
--
/Jacob Carlborg
On 2015-04-02 22:31, Dicebot wrote:
I don't think anyone is going to put those in a same inline style as
unittest blocks, so this is not truly relevant. At least I hope so.
You mean inline with the code it tests? No, I hope so too. I put my unit
tests in separate files as well, but that's
On 2015-04-02 21:21, weaselcat wrote:
no
this is the reason java is unusable without an IDE.
Yeah, in a Java IDE it would automatically add the missing imports.
--
/Jacob Carlborg
On 2015-04-02 21:11, Ary Borenszweig wrote:
We can. But then it becomes harder to understand what's going on. In
RSpec I don't quite understand what's going on really, and I like a bit
of magic but not too much of it.
It's quite straightforward to implement, in Ruby as least. Something
like
On 2015-04-10 21:02, Idan Arye wrote:
Many of these Vim users are not really Vim users - not in the sense that
Emacs users are Emacs users anyways. Sure, they use Vim - but only
because it's a default editor in Unix-like systems. If Windows Notepad
was the default text they wouldn't have
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 pointer, you have to register it at
compile time.
Yeah, this will require
On 2015-04-14 10:33, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
No.
No as in alloca doesn't work like that for default arguments or a
string mixin is still needed?
If alloca() ends up within a loop you are in a bad situation. Keep
in mind that alloca
On 2015-04-13 21:29, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
This is the best I can come up with currently. I think with a
@forceinline attribute, it would be a lot better, assuming `alloca()` is
usable inside an inlined method.
If I recall correctly alloca can be used as a
On 2015-04-14 11:50, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
It does work like that, but I don't see a way to pass the length to the
alloca() call. Unfortunately, we can't refer to other parameters. It
that were possible, it would indeed work:
import core.stdc.stdlib : alloca;
On 2015-04-20 16:29, Atila Neves wrote:
I saw links to PRs past with generated docs but have/had no
idea how to get a similar result. Besides the html make target,
what is it a person has to do exactly? I'm going to edit the wiki
with this information as well.
Some developer use Ddox [1],
On 2015-04-20 18:33, Dan Olson wrote:
An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces
the actual object file symbol while mangleof for C names strips a
leading underscore.
Is this intended? If so what is rationale?
I don't think it's intentional. The point of mangleof
On 2015-04-21 19:01, Dan Olson wrote:
Hmmm, I can see another point of view where mangleof should produce the
equivalent extern(C) symbol. My gut says this is the way it should
work.
That makes sense.
If I want to call a C function void debug(const char*) from a C library,
I would do this
On 2015-04-19 02:28, Michel Fortin wrote:
It's undocumented API, and they sometime change it although not that
much. Xcode 4 broke the plugin and I didn't put much effort into
figuring out what was wrong. Feel free to fork and fix it if you want,
the code is on Github.
On 2015-04-18 22:18, Dan Olson wrote:
Another approach is to use different IDE that can supports iOS dev
(download, debug). Not sure what is available, but these folks setup
Eclipse for Java iOS dev.
Xamarin [1] seems to have pretty good support for iOS development. They
collaborating with
801 - 900 of 3698 matches
Mail list logo
