Re: Avoiding allocation in broadcast server
On Saturday, 8 February 2014 at 17:49:24 UTC, Kagamin wrote: Client reads from the client? And what does the server? Server reads from client and broadcasts to clients.
Resolve function pointers using UDA during CT
Hi guys,
is there any way to create an function-array during CT using UDAs
like the following:
module myUdaFunctions;
struct MyUDA
{
string Name;
}
@MyUDA(Function1)
string myFirstUdaFunction(string myString)
{
// ... do something
}
@MyUDA(Function2)
string mySecondUdaFunction(string myString)
{
// ... do something
}
/
module myMain;
private
{
string function(string)[string] callbacks;
}
void main(string[] args)
{
// during ct:
{
// do something like this:
//
// auto u = __traits(getFunctionsByAttribute, MyUDA)
// foreach (myFunction; u)
//callbacks[myFunction.GetAttribute(MyUDA).Name] =
myFunction
}
// during runtime:
if (args[1] in callbacks)
{
callbacks[args[1]](myString);
}
}
Any way to do something like this?
Re: Resolve function pointers using UDA during CT
On Sunday, 9 February 2014 at 13:48:36 UTC, Philippe Sigaud wrote: callbacks[attribute.Name] = mixin( ~ symbol); callbacks[attribute.Name] = mixin(symbol);
Global imports vs scoped imports
I am working on a library, and I put all imports at the top of my source files under the module declaration. I was starting to think that it might be a good idea to start scoping some imports to reduce the number that might be used by a giving project, but how beneficial is this? Are there any kind of general rules for when to use module level imports vs scoped imports? Thanks! Jeremy
Re: Global imports vs scoped imports
On Sunday, 9 February 2014 at 19:12:21 UTC, Jeremy DeHaan wrote: I am working on a library, and I put all imports at the top of my source files under the module declaration. I was starting to think that it might be a good idea to start scoping some imports to reduce the number that might be used by a giving project, but how beneficial is this? Are there any kind of general rules for when to use module level imports vs scoped imports? Thanks! Jeremy Use scoped imports as much as possible. Those are completely superior to global ones. Pretty much only reason to have something as global import is if it is used in template constraints or vast majority of functions/methods of the module. Usage of selective imports is also encouraged. Main benefits are lazy evaluation and simplified maintenance - unused import become obvious, as well as symbol origins in function bodies.
Check if path is child of directory
I'm building a webserver using the Vibe.d library. Whenever the user requests a page inside my /images/ folder; I want them to output this file. Because there will be a lot of images present, and because these are likely to change in the future, I would like to just get the URL from the request, and automatically output the file. I am aware though, that users could perform tricks like images/../../../../sensitive_file_here. In order to prevent that I would like a solid way of making sure the entered path is actually inside the images directory. How do I do this?
Re: Check if path is child of directory
On Sunday, 9 February 2014 at 21:02:59 UTC, Jeroen Bollen wrote: I'm building a webserver using the Vibe.d library. Whenever the user requests a page inside my /images/ folder; I want them to output this file. Because there will be a lot of images present, and because these are likely to change in the future, I would like to just get the URL from the request, and automatically output the file. I am aware though, that users could perform tricks like images/../../../../sensitive_file_here. In order to prevent that I would like a solid way of making sure the entered path is actually inside the images directory. How do I do this? I just figured out vibe.d handles this automatically, but I'd still like to know of a secure way to do this, for future reference.
Re: Global imports vs scoped imports
On Sunday, February 09, 2014 19:12:19 Jeremy DeHaan wrote: I am working on a library, and I put all imports at the top of my source files under the module declaration. I was starting to think that it might be a good idea to start scoping some imports to reduce the number that might be used by a giving project, but how beneficial is this? Are there any kind of general rules for when to use module level imports vs scoped imports? The main place to use scoped imports in templated functions, because then the imports are only used if/when the template is instantiated. Outside of templated code, it's a matter of style and depends on how much in the module needs that import. For instance, if you're using std.range everywhere in a module, it's kind of silly to import it in every function in your module, as that's a lot of extra lines of code for little benefit. At that point, it's arguably better to just import it at the top. On the other hand, if you only using it within a handful of functions, by scoping the imports, it's clear what's using it, and if those functions all went away or were refactored such that they didn't need std.range anymore, then it would be clear that the imports could go away, whereas if the import is at the module level, it's not always obvious when you don't need it anymore. - Jonathan M Davis
Re: Global imports vs scoped imports
On Sunday, February 09, 2014 19:18:05 Dicebot wrote: Usage of selective imports is also encouraged. Not so much. At least, not right now. They don't work right and tend to cause symbol conflicts: https://d.puremagic.com/issues/show_bug.cgi?id=314 https://d.puremagic.com/issues/show_bug.cgi?id=8667 Now, once they're fixed, I could see an argument for using them, but until then, I'd advise staying away from them - at least in library code where the modules that you're writing are likely to be imported by other modules; it won't matter so much if it's the module with main in it and nothing is importing it. Certainly, using them in something like Phobos is generally a bad idea at this point. Personally, I'm not sure that I'd use them even once they're fixed unless I really only need one or two symbols out of the module, as it gets tedious otherwise, but I know that some people do really like the idea of making it very explicit which symbols are being used from a module being imported. - Jonathan M Davis
Re: Check if path is child of directory
On Sunday, February 09, 2014 21:09:51 Jeroen Bollen wrote: On Sunday, 9 February 2014 at 21:02:59 UTC, Jeroen Bollen wrote: I'm building a webserver using the Vibe.d library. Whenever the user requests a page inside my /images/ folder; I want them to output this file. Because there will be a lot of images present, and because these are likely to change in the future, I would like to just get the URL from the request, and automatically output the file. I am aware though, that users could perform tricks like images/../../../../sensitive_file_here. In order to prevent that I would like a solid way of making sure the entered path is actually inside the images directory. How do I do this? I just figured out vibe.d handles this automatically, but I'd still like to know of a secure way to do this, for future reference. std.path.absolutePath will take care of any ..'s at the beginning (which doesn't quite seem to be your problem here, but it might be useful depending on what you're doing). However, what you probably want here is std.path.buildNormalizedPath. Like buildPath, it can be used to construct a path from multiple strings, but if you give it only one string, it'll still work and will normalize it (it just won't have anything else to append to it like it would if you were really building a path). - Jonathan M Davis
Re: Check if path is child of directory
On Sunday, 9 February 2014 at 21:02:59 UTC, Jeroen Bollen wrote: I'm building a webserver using the Vibe.d library. Whenever the user requests a page inside my /images/ folder; I want them to output this file. Because there will be a lot of images present, and because these are likely to change in the future, I would like to just get the URL from the request, and automatically output the file. I am aware though, that users could perform tricks like images/../../../../sensitive_file_here. In order to prevent that I would like a solid way of making sure the entered path is actually inside the images directory. How do I do this? You can remove the directory navigation with std.path.buildNormalizedPath, not sure the behavior on a relative path, but you could call std.path.absolutePath first.
Re: pure vs writeln debugging
On Sunday, 9 February 2014 at 00:18:28 UTC, Nick Sabalausky wrote: On 2/8/2014 5:30 PM, Adam D. Ruppe wrote: On Saturday, 8 February 2014 at 22:27:39 UTC, Nick Sabalausky wrote: Is there some way to poke enough of a hole in pure to get some writeln debugging statements in? literally write debug writeln(..) abnd it should work in the pure function Nice! So I take it purity enforcement is disabled with the -debug flag? Or is it some sort of hack with writeln? It is a compiler benefit. Wish it would work with @safe and nothrow too, granted writeln should eventually be @safe/trusted anyway.
Re: Global imports vs scoped imports
On Monday, 10 February 2014 at 00:30:14 UTC, Jonathan M Davis wrote: On Sunday, February 09, 2014 19:18:05 Dicebot wrote: Usage of selective imports is also encouraged. Not so much. At least, not right now. They don't work right and tend to cause symbol conflicts: https://d.puremagic.com/issues/show_bug.cgi?id=314 https://d.puremagic.com/issues/show_bug.cgi?id=8667 Now, once they're fixed, I could see an argument for using them, but until then, I'd advise staying away from them - at least in library code where the modules that you're writing are likely to be imported by other modules; it won't matter so much if it's the module with main in it and nothing is importing it. Certainly, using them in something like Phobos is generally a bad idea at this point. Personally, I'm not sure that I'd use them even once they're fixed unless I really only need one or two symbols out of the module, as it gets tedious otherwise, but I know that some people do really like the idea of making it very explicit which symbols are being used from a module being imported. - Jonathan M Davis Awesome. Thanks for the information. I've found a few places I think it makes sense, but I was a little worried about doing it everywhere. Code bloat city.
Re: Circular Buffer
(disclaimer: I'm new around here) Is it possible to cycle backwards? If not, what's the best approach? Example of some ideal takeBack function: data = cycle([1,2,3][]) take(data, 4) is [1,2,3,1][] takeBack(data, 4) would be [1,3,2,1][] Thoughts?
Re: Circular Buffer
On Monday, 10 February 2014 at 03:14:31 UTC, Jonathan Dunlap wrote: (disclaimer: I'm new around here) Is it possible to cycle backwards? If not, what's the best approach? Example of some ideal takeBack function: data = cycle([1,2,3][]) take(data, 4) is [1,2,3,1][] takeBack(data, 4) would be [1,3,2,1][] Thoughts? Probably what you're looking for: http://dlang.org/phobos/std_range.html#.retro
