On Tuesday, 2 June 2015 at 08:54:46 UTC, ketmar wrote:
>
> sadly, this seems to get no "wow!"s. :-(

If no one knows about it, "wow!"s will not happen.  Make PRs.

-Wyatt

On 3/06/2015 1:33 a.m., ketmar wrote:
> On Tue, 02 Jun 2015 22:30:47 +1200, Rikki Cattermole wrote:
>
>>> * non-windows, as dll support on windows is still not here, i believe.
>>
>> I've been able to do it a little bit already with my Web server. Haven't
>> hit its limit so far. In other words as long as exceptions aren't used
>> and its never unloaded, should be ok. Anyway, do you really think we
>> would get that sort of support for a couple of releases?
>
> it seems that nobody on windows really needs that. ;-)
>
>
>> Indeed lets. But can we also not go modifying the language? I'm just
>> suggesting injecting of symbols that execute compiler side actions. Your
>> suggesting language changes. Even if it is a new pragma.
>
> actually, no language changes at all. CTFE is already here, and it is
> used in semantic analysis stage. there are no changes to the language,
> besides adding some hooks and defining an API. it's invisible from the
> user's POV and doesn't require changing of specs. now CTFE is started
> explicitly, by using mixins and template evaluation. with my idea it will
> be started implicitly when some condition is met. sure, that conditions
> must be documented, but it will not change the language drastically.

Nope, it can be just another function call.

------
auto something(string text);

@something("...")
void another() {

}
------

Where something is specified on the compiler side.
UDA's + static assert imply compile time literals, which is what we want.

Something that is important to note is, these symbols like something defined by the compiler should never hit the backend. If they are referenced they should be forced to be called.

>> We really need to toy with these ideas properly and implement each. Then
>> its just a matter of time to convince the higher ups that it should be
>> merged.
>
> yes, i believe that this is the best approach. implement both and let the
> best solution win in a honest competition. ;-)
>
> i don't feel very creative right now, but implementing that idea is in my
> TODO list, and it's not at the bottom of list. so eventually (month? two?
> ten years?) i'll write a PoC.

I think we want something very similar. We just haven't quite merged our ideas just yet.

Well, there's this thread now:

http://forum.dlang.org/thread/ranqlmrjornlvopsuris@forum.dlang.org#post-ranqlmrjornlvopsuris:40forum.dlang.org

Atila

On Tuesday, 2 June 2015 at 13:22:25 UTC, ketmar wrote:
> On Tue, 02 Jun 2015 12:12:06 +0000, Atila Neves wrote:
>
>>>> https://github.com/atilaneves/reggae
>>>> 
>>>> Atila
>>>
>>> hm. looks interesting, albeit a little too noisy for my taste.
>> 
>> It depends on what you want to do: the idea is to use high-level utility
>> functions as much as possible, while at the same time offering low-level
>> primitives that those high-level ones are based on.
>> 
>> If it can be made simpler, I'd really like to know.
>
> not that i have something better to offer. it's readable and looks fine.
> besides, i'm really sux at design things. ;-)

On Tue, 02 Jun 2015 13:44:10 +0000, Wyatt wrote:

> On Tuesday, 2 June 2015 at 08:54:46 UTC, ketmar wrote:
>>
>> sadly, this seems to get no "wow!"s. :-(
> 
> If no one knows about it, "wow!"s will not happen.  Make PRs.

i mentioned the idea several times in NG, it fades almost without any attention. honestly, i have alot of hobby projects, so before writing such complex things (and it's fairly complex, considering design and documentation) i want to know if there will be enough attention to it.

as people seems to pass it by, i have no motivation of doing that work. i have alot of things i want to add to Aliced, so no "wow, that would be nice to try!" replies means "move that down in my TODO list".

On Wed, 03 Jun 2015 01:48:13 +1200, Rikki Cattermole wrote:

> Nope, it can be just another function call.
> 
> ------
> auto something(string text);
> 
> @something("...")
> void another() {
> 
> }
> ------
> 
> Where something is specified on the compiler side.
> UDA's + static assert imply compile time literals, which is what we
> want.

for me UDA syntax that actually calling some function seems counterintuitive. like "well, i know that it's a simple declaration... WUT?! how it managed to execute the code?!"


> I think we want something very similar. We just haven't quite merged our ideas just yet.

yes, seems that it's the same goal, but slightly different approaches. i think i should do a draft for API and write some explanations first, so it can be discussed in details. 'cause now i have a foggy picture in my head which is hard to describe.

On 06/02/2015 02:53 AM, Jacob Carlborg wrote:
> On 2015-06-01 20:39, Nick Sabalausky wrote:
>
>> Unlike rdmd, dub always tries to compile all sources regardless of
>> whether they're actually imported. This has been a constant source of
>> problems for me, including breakage of conditional importing under
>> various circumstances.
>
> Isn't that the only way to compile it if the project is a library?
> without having to use workarounds like create a new module which imports
> all other modules.
>

My libs always have a "package.d" or equivalent anyway, so I don't find it to be any sort of "workaround".

Even without that, rdmd-style still works if the lib is being used as a source lib rather than a pre-compiled static (or dynamic) lib.

But yea, if you're doing a precompiled lib and you don't want any sort of "root" module (don't see it as all that big of a deal though), then yea I guess you'd have to collect the list of sources dub-style instead of rdmd-style.

On 6/2/15 3:12 AM, Jacob Carlborg wrote:
> On 2015-06-01 20:49, Steven Schveighoffer wrote:
>
>> I'm not defending DIP11, just that the fact that it could be done
>> without requiring an extra "dependencies" file.
>
> One usually needs a file to set all compiler and linker flags and other
> kinds of configurations. Dub allows you to do this as well in
> cross-platform way. So when you already have all that, just put the
> dependencies there and be done with it.
>

Actually, I don't. dmd *.d generally works fine.

-Steve

On 06/02/2015 01:03 AM, Nick Sabalausky wrote:
> On 06/01/2015 03:59 PM, Nick Sabalausky wrote:
>> On 06/01/2015 03:46 PM, Andrei Alexandrescu wrote:
>>>
>>> rdmd could collect dependencies while performing the actual compilation.
>>> Then, if the dependencies are stable (compare with the saved ones), all
>>> done in one run. Otherwise, discard the output and rebuild.
>>>
>>
>> Hmm, actually, that's a good idea.
>>
>>> This can be implemented today. Would you want to work on it?
>>>
>>
>> I've gotten rusty on RDMD's internals, but I'll take a look, see what I
>> can manage.
>>
>
> Unfortunately, I've hit a bit of a problem: "dmd -v" doesn't emit an
> "import  module_name (path/to)" line for imports that were provided on
> the command line.
>
> Aside from the minor issue of it complicating parts of the code, this
> makes it impossible (AFAICT) to distinguish between "the deps have not
> changed" vs "a former dep is no longer imported and should no longer be
> compiled".
>

Related to this, does anyone happen to recall why rdmd uses "dmd -v" to get dependencies instead of "dmd -deps"? IIRC, it used to use -deps back at one time.

On Tuesday, 2 June 2015 at 07:02:50 UTC, Jacob Carlborg wrote:
> On 2015-06-01 18:56, Dicebot wrote:
>
>> Though it is hard to invent a package management for interpreted
>> language that is not insane. It is much better with native ones because
>> runtime dependencies are separated from development dependencies.
>
> Rubygems supports development dependencies.

You must have though of different "development dependencies". I don't mean tools and stuff like that but all sorts of small static libraries (in native compilation world). With scripting language this unavoidably propagates on the end user unless you merge all deps into your sources inline for distribution (which no one does).

On Tuesday, 2 June 2015 at 09:15:13 UTC, Atila Neves wrote:
> https://github.com/atilaneves/reggae
>
> Atila

If this works up to the expectation, I will only need to write a simple code.dlang.org package fetcher and will never need to use dub again :)