D needs to solve its GUI problems. We need unified solutions for things. No more hundred libraries to do one thing poorly.
No small libraries that do one thing very well are what is needed. And I intend to get the snowball rolling.
Showing posts with label D. Show all posts
Showing posts with label D. Show all posts
Friday, November 7, 2014
Wednesday, August 27, 2014
Survey analytics, mixins!
Currently I'm working on my Degree in ICT industry project. For this I am using D.
I'm currently in the requirements phase and doing some requirements gathering. To make sense of all this data I'm writing a tool in D to analyse it.
I'm currently in the requirements phase and doing some requirements gathering. To make sense of all this data I'm writing a tool in D to analyse it.
Sunday, August 17, 2014
Swift is so cuckoo
Last day or so, I've been having a little play around on my new Mac Book Pro. Rather a nice machine. Anyway what I was trying to do is get create a window that I could hook into by D. The idea was to get DWC (D window creation), little library I'm working on for fun. To work on Mac OSX natively.
Monday, August 11, 2014
Its alive! livereloading I mean
Last few weeks, I've been working on a nifty approach to get livereloading of e.g. templates at runtime within D. But I've had quite a few problems along the way. Let me explain.
Wednesday, July 23, 2014
Refactoring away the blues
As a developer, one of my greatest tools is the ability to refactor away and redesign an API after it was initially written. Making it more fundamentally easier to understand and use. But there is also another side of the coin that we don't touch upon quite often. Making it more flexible.
Sunday, July 6, 2014
Hosting a VM, OpenGL and SSH
Wednesday, June 25, 2014
Future is bright, I think?
I'm coming up to a major part of my life. Not anything like marriage however. My BCCE301 industry project.
Where by I will be working with industry to do a project in some form. Now my plan is to start to a company where by making a web service utilising D.
Ignoring the major issue of money in doing so, what other challengers will I have in doing this?
Where by I will be working with industry to do a project in some form. Now my plan is to start to a company where by making a web service utilising D.
Ignoring the major issue of money in doing so, what other challengers will I have in doing this?
Monday, April 21, 2014
Update: last few weeks
I don't really normally do update blog posts, but I feel that it is a good idea this time.
So during last week I had the flu. A pretty nasty one at that. While that stopped me pretty much programming during it, it did allow me to gain a new perspective on things.
So during last week I had the flu. A pretty nasty one at that. While that stopped me pretty much programming during it, it did allow me to gain a new perspective on things.
Sunday, April 6, 2014
D has actors now!
Okay so recently it came up in the D newsgroup about akka. Akka is a pretty cool framework (Java/Scala) for multi cpu/host/thread processing of information. It also has a high degree of trust around 'its going to fail so lets handle it'.
Sunday, March 30, 2014
CTFE where can it go?
Over the past five months I've been working quite a lot on Compile Time Function Execution (CTFE) and what I keep seeing is at the current point in time, a lot of crazy stuff can be done. But netherless very very neat.
Wednesday, March 12, 2014
Compile Time Function Execution, a pattern to go by
I've been working quite heavily with Compile Time Function Execution (CTFE) and D's meta programming (templates). Each of these being quite innovative. But paired together they are quite useful.
From generation of code, to handling of UDA's.
From generation of code, to handling of UDA's.
Sunday, February 9, 2014
Does _your_ data model create your javascript?
So still early days, but currently I'm working on creating javascript from D data models.
Why would anyone want to do this exactly? And how did I come to this?
Why would anyone want to do this exactly? And how did I come to this?
Friday, January 17, 2014
Porting, the loss of the age!
Last few days I have been having a play round with porting GLFW to D. But why would I do this since its a C library?
Friday, January 10, 2014
Creating a competing web service framework with D
One of D's current target audiences is web developers. For medium to large web sites. To provide for this a framework is generally expected to speed up development times.
Because of this I have started working on Cmsed. I describe it as a Web development component library. Not a web service framework. Why did I do that?
Because of this I have started working on Cmsed. I describe it as a Web development component library. Not a web service framework. Why did I do that?
Thursday, January 2, 2014
Website development, D/Vibe-d vs PHP
Lately I've been working quite heavily in website development using D. More specifically Vibe. Coming from a PHP background this has shown to me just how different the two ecosystems really are.
Saturday, November 30, 2013
Its all in the interpretation!
A big problem with having a web service that is designed to be highly user centric is allowing them to customize their experience of the site safely.
You can allow them to modify things like themes under your own control. But what about actual content? What CONTENT can you allow them to manipulate? This is a big risk in terms of security and privacy over all. Most web services because of this limit it to highly predefined things like some text.
So how am I looking to do it? First off there is two portions to a system that I am suggesting.
You can allow them to modify things like themes under your own control. But what about actual content? What CONTENT can you allow them to manipulate? This is a big risk in terms of security and privacy over all. Most web services because of this limit it to highly predefined things like some text.
So how am I looking to do it? First off there is two portions to a system that I am suggesting.
- Front end, where the actual editing goes on.
- Back end, verification and manipulation of site content.
Tuesday, November 26, 2013
Web services and OpenGL oh my!
Interesting title you might say of this post. Given that OpenGL is far more related to desktop applications then servers. What I'm actually referring to is two different sets of projects. For OpenGL I am referring to DOOGLE my little GUI toolkit written in D. With regards to the web service, I can't say too much at this point about the purpose however I can for some of its elements.
Saturday, March 16, 2013
Java, past and future
In the past two years a lot has changed and happened. We in (Christchurch New Zealand) have had our lives turned up side down by earthquakes and bureaucracy. The 'skynet' law came into being and all the debarkle about SOPA, PIPA and all the related proposed bills in the United States.
But none of this is what I am here talking about; Java. I am talking about Java and how it has changed.
But none of this is what I am here talking about; Java. I am talking about Java and how it has changed.
Wednesday, February 20, 2013
Allegro the static beast
Recently I wrote an article on compiling Allegro. Please note this was only for a dynamically linked library.
Now for a statically built library!
Now for a statically built library!
Labels:
64bit,
allegro,
Build,
C,
C++,
code,
Compile,
D,
Static libraries,
Static library,
Visual Studio,
Windows
Saturday, January 19, 2013
D dynamic runtime function calling
Recently I did some work towards making a dynamic function caller in D. Note this is a very unsafe operation in such a language.
The premise is simple take any argument and then call a function without a return type.
The answer didn't appear as simple though.
I manually pushed to the stack the arguments then called using a pointer which has been casted to void the function.
Great it works! But umm how do we push arguments to the stack? That is the hard part.
Primitives have to be dealt with individually. Structs have no super type and Objects aka classes have the Object super type so very easy. Arrays are also a type so they are easy to do when registering a type. Last associative arrays a type that requires two other types to make it; not so easy.
I got Objects, primitives, arrays and any other type you manually register. Why the registering? Because I used the Variant type and this is where it all falls apart.
The Variant type is great for storing and retrieving values out off, IF you know the type at compile time for when you retrieve it.
So using templates I created a registration system that created a function that was designed specifically for a type you register.
Most of the time it was a non issue with calling the get!type function on Variant and then just exiting the function created but some which types use a more complex pointer values in registers had to be modified to be allowed for.
Also the float type was stored in different registers different from other types its size. I implemented the registration system to allow for system level types and user types. The system types have the override for said type that was manually implemented.
How could this have been done simpler?
In short a container type that allowed for pushing the value directly on to the stack without knowing its type. Because the type and hence its size was known directly at creation I don't need to know it when pushing; it should have been retrieved and stored then (value.sizeof).
This would have void'd the need for the registration system completely.
To see this check out link.
I hope this gives you all some ideas; but remember this is not safe,even if I called it that. D is simply not the right type of language to do any sort of reflection type activity like this.
The premise is simple take any argument and then call a function without a return type.
The answer didn't appear as simple though.
I manually pushed to the stack the arguments then called using a pointer which has been casted to void the function.
Great it works! But umm how do we push arguments to the stack? That is the hard part.
Primitives have to be dealt with individually. Structs have no super type and Objects aka classes have the Object super type so very easy. Arrays are also a type so they are easy to do when registering a type. Last associative arrays a type that requires two other types to make it; not so easy.
I got Objects, primitives, arrays and any other type you manually register. Why the registering? Because I used the Variant type and this is where it all falls apart.
The Variant type is great for storing and retrieving values out off, IF you know the type at compile time for when you retrieve it.
So using templates I created a registration system that created a function that was designed specifically for a type you register.
Most of the time it was a non issue with calling the get!type function on Variant and then just exiting the function created but some which types use a more complex pointer values in registers had to be modified to be allowed for.
Also the float type was stored in different registers different from other types its size. I implemented the registration system to allow for system level types and user types. The system types have the override for said type that was manually implemented.
How could this have been done simpler?
In short a container type that allowed for pushing the value directly on to the stack without knowing its type. Because the type and hence its size was known directly at creation I don't need to know it when pushing; it should have been retrieved and stored then (value.sizeof).
This would have void'd the need for the registration system completely.
To see this check out link.
I hope this gives you all some ideas; but remember this is not safe,even if I called it that. D is simply not the right type of language to do any sort of reflection type activity like this.
Subscribe to:
Posts (Atom)