Re: [OT] HTML: div/iframe hybrid?
On Saturday, 7 March 2015 at 17:01:14 UTC, Nick Sabalausky wrote: On 03/06/2015 07:16 AM, Kagamin wrote: Just posted: http://jonrimmer.github.io/are-we-componentized-yet/ Is it what you need? No, what I was looking for was a way to do "Just drop these few lines of code into your HTML" a la Disqus Hate when websites do things like that. I will take JS any time over it. It has become slightly better with same origin policy but generally if website has iframe most likely it either looks horribly out of style or is abused for malicious means.
Re: Standard GUI framework inspired by Qt
On Tue, 10 Mar 2015 01:25:03 +, karl wrote: > Please don't use SDL2 and such as basis what is wrong with SDL2? it doesn't use `glReadPixels()`, afair. and if it's doing something very wrong, and you know how to made it better, would you please fill bugreport? signature.asc Description: PGP signature
Re: Standard GUI framework inspired by Qt
Please don't use SDL2 and such as basis, or OpenGL with glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm a GL driver dev (userspace) for a smaller company, and I see too much gore in popular software like that (gnome3 is the most-horrific). A fully-featured GUI with GL needs only a thin wrapper for glXGetProcAddress, GL context creation, BitBlt-like things and font-glyph cache (or better yet, signed-distance-field text rendering). Something like this: Base (sans clipping, I haven't ported it from asm yet): https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw SDF text: https://www.mapbox.com/blog/text-signed-distance-fields/ Also, GL should be optional, just like with Qt; it introduces noticeable lag of 16 to 48ms while being a resource hog unnecessary for most apps. I could help with implementing the abstraction layer and create a software blitter (I was professionally doing such stuff before, for GUI toolkits and stuff; but then again this stuff is trivial). A 32-bit backing-store is always vital (DDB+GDI dibsection, GL texture and such). Qt has it (and implemented really-well) and that's the first pixel-related thing we should implement. BGRA8 will be the best format (blue in LSB). A 9-cell blit will also be vital functionality.
Re: [NEEDING HELP] Translation of Ali Cehreli's book in French
Le 09/03/2015 19:46, Scroph a écrit : Thanks for the replies everybody. I read them all, and in the end, I decided to translate "members" into "champs" and kept "méthodes" for member functions. However, this isn't final, and you are all welcome to make further suggestions. @Raphaël : I just sent the translated version to the email address you posted, thanks for giving me the opportunity to participate in this work. I'll translate another chapter as soon as I have some time on my hands. Thank you for participating! To the people who sent me their work these last days: I received it, I have little time to handle it at the moment. If you think it is too long, don't hesitate to send me an email though. Sorry for the delay.
Re: What Features Should A GUI toolkit have?
On Friday, 6 March 2015 at 06:02:17 UTC, Taylor Hillegeist wrote: So I have played with a few GUI libraries with bindings available through D. Personally I find that it seems like there is alot of effort being put forth on GUI projects. It is my experience that most project's fail or die, not because of lack of effort but lack of specification, many people start projects thinking, can i make it do this? how about this? and a project is born! but soon interest is lost and the project dies. But specification can lead to projects that become useful earlier, more stable, and live longer happier lives. At this point i think the following features are the most useful. -Ease of setup- dub integration is awesome, without it things are more difficult. This has very little to do with the actual toolkit. -Minimal dependencies- Personally If i can statically link a toolkit to my GUI and it has zero dependencies outside of the OS typically install. I am very happy. really the less that can be messed with the better. best in my opinion: DWT MiniGUI DGUI at least for windows. -Rock Solid Stable- So when I do the hello world application I resize the window push the buttons and do pretty normal things. But on some libraries I get weird stuff going on sometimes the window even becomes invisible. scary. best in my opinion: GTKD TKD -GUI EDITOR/BUILDER- Good- You can edit a static layout Better- you can edit a layout and re-size the window layout responds Best- you can edit the actual window in real time without recompile. Good- You have a pallet of basic widgets that you can place. Better- You have a pallet of basic widgets + custom widgets that you can edit. Best- You have the above + a database were people can share widgets :) -Widgets- Personally I think that all layout items like HBar should be children of widget that way i can make more modular component, but that's just my opinion. -Data Binding- Most of the time I use that data a widget represents and much less often the events they produce. -Ease of Use- Your tookits should work for you... not the other way round. -layout- I have seen some schemes like Winforms Dock,javaFX HBar, HTML5's float/static/absolute/realitive... Idk what seems the most freindly... HTML5/css seems the most complex. I have a dream H/VBar + align/distribution/wrap options. I know some of these are RAD things. I don't have an opinion on thread safe guis. personally I would like to see a GUI tookit that the community said... use X it is just the way to go for most things. Click-able buttons A GUI toolkit should have...Click-able buttons rocks ! More seriously, one of the problem which explains why there no well-established GUI library around is the lack of serialization, component streaming solution. Currently there is no standard way in D to save and reload a class instance or a struct.
Re: [OT] HTML: div/iframe hybrid?
On 03/08/2015 04:31 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: On Saturday, 7 March 2015 at 17:01:14 UTC, Nick Sabalausky wrote: I haven't looked at the details, but "HTML Imports" sounds like something that might have been able to fit that, but according to that page, not only do Safari and IE not support them, but apparently Firefox is INTENTIONALLY not doing them because (if I understand this "polyfill" thing right) it seems Mozilla deliberately wants to force basic things like that to always rely on JS. No, I think they just want to make sure it is the right way to do it before it is implemented. The polyfill webcomponents-lite.js should give HTML import and templates for IE11+: https://github.com/WebComponents/webcomponentsjs#browser-support Well, the problem with polyfill is that it defeats the whole point. Pretty much anything can *already* be done via cross-browser JS libs. But some things have no justification for requiring ANY of the bloat or bother of JS - hence "a href", ":hover", seamless iframes, html imports, and many other examples. So polyfill accomplishes nothing - it's little more than a new name for what we've ALWAYS had: over-reliance on JS libs for basic, basic functionality.
Re: [dmd-internals] DMD now requires a working D compiler to be build
On 2015-03-09 15:40, Vladimir Panteleev wrote: That has the year in the URL though... This might be easier: http://downloads.dlang.org/releases/2.x/ -- /Jacob Carlborg
Re: [NEEDING HELP] Translation of Ali Cehreli's book in French
Thanks for the replies everybody. I read them all, and in the end, I decided to translate "members" into "champs" and kept "méthodes" for member functions. However, this isn't final, and you are all welcome to make further suggestions. @Raphaël : I just sent the translated version to the email address you posted, thanks for giving me the opportunity to participate in this work. I'll translate another chapter as soon as I have some time on my hands.
[OT] Exploiting the DRAM rowhammer bug to gain kernel privileges
I'm just leaving this here :) http://googleprojectzero.blogspot.fr/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
Re: [dmd-internals] DMD now requires a working D compiler to be build
"Vladimir Panteleev" wrote in message news:bbnllblbmhtjnkmdt...@forum.dlang.org... That has the year in the URL though... Can I get that programmatically, other than by querying the git tag? Not that I know of.
Re: RCArray is unsafe
On 04/03/2015 08:55, Ivan Timokhin wrote:
void main()
{
auto arr = RCArray!int([0]);
foo(arr, arr[0]);
}
void foo(ref RCArray!int arr, ref int val)
{
{
auto copy = arr; //arr's (and copy's) reference counts are both 2
arr = RCArray!int([]); // There is another owner, so arr
// forgets about the old payload
} // Last owner of the array ('copy') gets destroyed and happily
// frees the payload.
val = 3; // Oops.
}
We could prevent reassignment of arr while val is alive, but perhaps
still allow mutation of existing elements through arr.
I've changed Marc Schütz's example to explore this:
void main() {
auto a = RCArray!int([5]); // a's refcount is now 1
foo(a, a[0]); // pass by ref
}
void foo(ref RCArray!int a, ref int t) {
a[0] = 4; // ok
a = RCArray!int([]); // drop the old a
t = 3; // oops, t is gone
}
I think Rust would enforce that either a *or* t can be mutably borrowed
at once (and for a, t can't even be immutably-borrowed). Without
designing a system, in theory foo is OK if a is const, but that prevents
a[0] = 4. This could be allowed as long as a is not reassigned (i.e. a
is head-const).
To support RCDynamicArray that supports appending and resizing, these
operations also need to be excluded, whilst potentially allowing
existing elements to be mutated.
(I've seen Andrei's solution for the above example, but it doesn't work
for Ivan Timokhin's code, and for the former it can be non-ideal).
Perhaps a parameter attribute similar to head-const (but somehow
configurable by the container author) could enforce this. The author of
foo would need to use this attribute for a. The container could mark the
safe mutation operations with this attribute.
Just an idea. I haven't considered other types of container, maybe it
would help those also.
Re: [dmd-internals] DMD now requires a working D compiler to be build
On Monday, 9 March 2015 at 13:32:10 UTC, Daniel Murphy wrote: "Vladimir Panteleev" wrote in message news:bujssfggzyassdtzd...@forum.dlang.org... It depends, do we have a stable URL structure for DMD downloads so that you can build a working download URL with only the platform and version? Sorta http://downloads.dlang.org/releases/2014/ That has the year in the URL though... Can I get that programmatically, other than by querying the git tag?
Re: What Features Should A GUI toolkit have?
On Monday, 9 March 2015 at 12:29:54 UTC, Ola Fosheim Grøstad wrote: Some applications that use Chromium Embedded: http://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Applications_using_CEF I don't use any of them and Github for Windows was done in WPF last time I checked, how come it is listed there? -- Paulo
Re: [dmd-internals] DMD now requires a working D compiler to be build
"Vladimir Panteleev" wrote in message news:vdwvdnzzzhenuybcb...@forum.dlang.org... What about source Linux distributions, like Gentoo? What do other self-hosted languages do in this situation? Download the zip.
Re: [dmd-internals] DMD now requires a working D compiler to be build
"Vladimir Panteleev" wrote in message news:bujssfggzyassdtzd...@forum.dlang.org... It depends, do we have a stable URL structure for DMD downloads so that you can build a working download URL with only the platform and version? Sorta http://downloads.dlang.org/releases/2014/
Re: [dmd-internals] DMD now requires a working D compiler to be build
On Monday, 9 March 2015 at 01:26:10 UTC, Daniel Murphy wrote: "Walter Bright" wrote in message news:mdiqav$17i8$1...@digitalmars.com... On 3/8/2015 5:00 PM, Daniel Murphy wrote: > If it's a new platform, why would 2.067 be able to target it? Because it'll have a C++ compiler. You'd be able to compile the C++ version of 2.067 on this platform, but 2.067 still wouldn't be able to target that platform without patches. Wouldn't it be easier to add support for the new platform into the latest compiler and cross-compile? IIRC you did something like this in the past when targeting new platforms. What about source Linux distributions, like Gentoo? What do other self-hosted languages do in this situation?
Re: [dmd-internals] DMD now requires a working D compiler to be build
On Monday, 9 March 2015 at 10:47:06 UTC, Daniel Murphy wrote: "Vladimir Panteleev" wrote in message news:njvvnodefqmrhzbux...@forum.dlang.org... A machine-readable version is preferable because then Digger can consult it to know which pre-built DMD version to fetch. Yes. Any preference on the name? Not really. There is the VERSION file, maybe something like that. If we had somewhere a machine-readable list of all DMD releases with binaries for major platforms plus release dates, it could use that as well, and just use the latest stable release for the point in time which the source code to be built is from. Can that be generated from the git tags? It depends, do we have a stable URL structure for DMD downloads so that you can build a working download URL with only the platform and version?
Re: What Features Should A GUI toolkit have?
Some applications that use Chromium Embedded: http://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Applications_using_CEF
Re: [dmd-internals] DMD now requires a working D compiler to be build
"Vladimir Panteleev" wrote in message news:njvvnodefqmrhzbux...@forum.dlang.org... A machine-readable version is preferable because then Digger can consult it to know which pre-built DMD version to fetch. Yes. Any preference on the name? If we had somewhere a machine-readable list of all DMD releases with binaries for major platforms plus release dates, it could use that as well, and just use the latest stable release for the point in time which the source code to be built is from. Can that be generated from the git tags?
Re: [dmd-internals] DMD now requires a working D compiler to be build
On Monday, 9 March 2015 at 04:01:26 UTC, Daniel Murphy wrote: "Vladimir Panteleev" wrote in message news:sjlsydcjflglxpwus...@forum.dlang.org... OK, then can a file please be added to the DMD source repo which indicates which host DMD version is needed to build it? This seems reasonable. We could also add a static assert to provide a helpful error message when attempting to build with older versions A machine-readable version is preferable because then Digger can consult it to know which pre-built DMD version to fetch. If we had somewhere a machine-readable list of all DMD releases with binaries for major platforms plus release dates, it could use that as well, and just use the latest stable release for the point in time which the source code to be built is from.
Re: [dmd-internals] DMD now requires a working D compiler to be build
On 9 March 2015 at 08:44, ketmar via Digitalmars-d wrote: > On Mon, 09 Mar 2015 00:12:47 -0700, Walter Bright wrote: > >> On 3/8/2015 8:43 PM, Daniel Murphy wrote: >>> "Walter Bright" wrote in message news:mdj3l3$1hup$1...@digitalmars.com... >>> Never needed to build a cross compiler. >>> >>> You did when adding 64-bit targets. ie dmd is a 32->64 and 64->32 >>> cross compiler. >> >> Not really. I never had to compile one one machine and copy the result >> onto another. > > so do you mean that if i need to compile under GNU/Linux, but have > compiler to produce windows PE, that means that i'm not doing cross- > compile? no, i will not copy the resulting PE anywhere, i'll test it > right on the same box. > > a very interesting definition of cross-compilation and cross-compilers... There's a difference between cross-compiling for a wholly different platform/architecture vs. compiling on a multiarch-aware platform/cpu (such as 64->32).
Re: Standard GUI framework inspired by Qt
On Mon, 2015-03-09 at 08:56 +, Dejan Lekic via Digitalmars-d wrote: […] > > I would rather have a GUI framework inspired by JavaFX, plus some > features that could be added on top of it, that are related to > the fact that D programmers can utilize hardware directly. JavaFX > is in my humble opinion one of the best designed GUI APIs in > existence today. Similar D API would be smaller because we would > get rid of typical Java bloat. And using GroovyFX to code it gets rid of much of the Java bloat. Sadly the JavaFX team have created a nice piece of infrastructure but forget to mention that coding it using Groovy is way easier that using Java. Of course using a UI development framework such as Griffon makes things even easier. http://new.griffon-framework.org/ -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Standard GUI framework inspired by Qt
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote: Hi all I've been thinking over a GUI framework for D for some time, and ended up with idea expressed by Andrew Fedoniouk here: http://www.digitalmars.com/d/archives/digitalmars/D/32633.html. That is, having a separate drawing layer, and widgets built on top of it. But since it has already been discussed 9 years ago, I wonder if such a framework has ever been implemented. In that duscussion many participants agreed that Qt would be a good foundation, but had very restrictive license. Things have changed since then, and Qt now is available under LGPL, which, to my undestanding, makes it suitable for the purpose of standard GUI library (please correct me if I am wrong on this). The license, of course, may change in the future, preventing us from using their updates for our drawing engine. But if we are able to start using the engine now, in the future we can maintain the updates ourselves. Now, how I envision the library's design: The library will be mostly implemented in D, except for drawing engine and event loop, which are system-dependent. Those two parts will be extracted from Qt into a separate library which will be linked to by the rest of framework either statically or dynamically. There will be bindings for sending drawing instructions to drawing engine, as well as for retrieving system and GUI events from event loop. The system-independent part will mimic architecture of Qt. However, for maximum flexibility and customizability, GUI will utilize QML+CSS approach, and Qt's layout manager classes will be dropped completely. Also there is no need to port classes that are available in D, such as collections and strings. If there is no standard GUI for D yet, and if LGPL license fits our purpose, then I am looking for 2-3 Qt experts to join me and build the framework. Thanks, Aram I would rather have a GUI framework inspired by JavaFX, plus some features that could be added on top of it, that are related to the fact that D programmers can utilize hardware directly. JavaFX is in my humble opinion one of the best designed GUI APIs in existence today. Similar D API would be smaller because we would get rid of typical Java bloat.
Re: [dmd-internals] DMD now requires a working D compiler to be build
On Mon, 09 Mar 2015 00:12:47 -0700, Walter Bright wrote: > On 3/8/2015 8:43 PM, Daniel Murphy wrote: >> "Walter Bright" wrote in message news:mdj3l3$1hup$1...@digitalmars.com... >> >>> Never needed to build a cross compiler. >> >> You did when adding 64-bit targets. ie dmd is a 32->64 and 64->32 >> cross compiler. > > Not really. I never had to compile one one machine and copy the result > onto another. so do you mean that if i need to compile under GNU/Linux, but have compiler to produce windows PE, that means that i'm not doing cross- compile? no, i will not copy the resulting PE anywhere, i'll test it right on the same box. a very interesting definition of cross-compilation and cross-compilers... signature.asc Description: PGP signature
Re: [dmd-internals] DMD now requires a working D compiler to be build
On Mon, 09 Mar 2015 02:18:31 +1100, Daniel Murphy wrote: > I would prefer long periods between host compiler version bumps, but is > building completely from source really a concern? sure it is. one more windoze .exe to call for cross-building dmd.exe in GNU/Linux. i managed to make it partially buildable with cross-mingw (kawabanga!), and now it all again... also, treading crash bug still not fixed, so vanilla dmd.exe keeps crashing with my wine. oh, crap... how i hate it. signature.asc Description: PGP signature
Re: What Features Should A GUI toolkit have?
On Saturday, 7 March 2015 at 07:33:03 UTC, Russel Winder wrote: I meant a user interface not using a browser as the infrastructure. Cocoa, Qt, GTK, JavaFX, etc. are all there already, and have everything browsers are still trying to get. All I can say that you can cut down on development time, get better portability, greater reuse and greater flexibility by using HTML5. The only downside has been performance and toolkits, but that is changing over time. Shadow DOM is an essential component to that, by encapsulating GUI elements, and reactive frameworks allows you to tie them together with effortless two-way binding. but it's only real positive is that it is (supposed to be) pre-installed and the same on every machine. Sadly though, from what I can see, vast amounts of code and time is spent dealing with the differences between browsers. That's in the past. The time spent referencing caniuse.com (about once every 15 minutes for me) allows you to use new features without having to reimplement for another browser. I spend less than 1% on cross browser issues now that I am on IE10+. Before that, 10-20%. But that is not relevant here, since we are talking about building Chromium into the app, as in statically. HTML and Javascript may have an edge on ease of deployment, but regarding the other dimensions, I fear you must have imbibed of the Kool-Aid. No Kool-Aid, just a fair knowledge about usability, GUIs and the cost of doing native development as well as what browser engines now provide. Going native costs you twice as much in GUI work than a design that fits HTML5. HTML is by far the most stable and portable platform over time... Because it is backed by an adopted standard. Without a standard, it would be worth nothing. Low risk implies adoption. Flexibility is also important for creating good UIs. Complex applications never reuse much from existing GUIs, they create their own for all the critical tasks. That applies to just about all applications where screen estate and workflow matters: audio-visual applications, CAD etc. Clearly new technology and new application require new things, but simply ignoring already known stuff is just wrong. I am not ignoring anything. I am pragmatic, and I also know the UI theory and what the portable UI frameworks has offered since the 1980s. HTML5 is an adopted agreed upon standard with backwards compatible enhancements that works cross platform. Everything else is not. Therefore HTML5 will grow more over time. Just like C++ will grow more than D...
Re: [dmd-internals] DMD now requires a working D compiler to be build
"Walter Bright" wrote in message news:mdjj01$22eo$1...@digitalmars.com... As far as I'm concerned, if it's running on the same machine, it is not a cross compiler, it's a different memory model. I... I don't agree. But luckily it doesn't matter.
Re: [dmd-internals] DMD now requires a working D compiler to be build
On 3/9/2015 12:30 AM, Daniel Murphy wrote: "Walter Bright" wrote in message news:mdjh6g$215p$1...@digitalmars.com... Not really. I never had to compile one one machine and copy the result onto another. It doesn't have to be cross-architecture to be a cross compiler. As far as I'm concerned, if it's running on the same machine, it is not a cross compiler, it's a different memory model. How easy it is to copy the files over would decide which method is more convenient. Besides, it is likely the vast majority of the work would be in the back end, which remains in C++. I guess that makes sense. It should be easier to apply a backend patch to two versions than it would be with a large frontend patch. Anyway, after the new platform is brought up, the original 2.067 still won't be able to target it and will therefore no longer be a suitable minimum host compiler version. This could be fixed by creating a point release for 2.067 that includes the new platform support, or by bumping the version requirement to the latest release. If we're talking months, then a point release is reasonable. If 2.067 is years old by then, it's probably best to bump the requirement. Yup.
Re: [dmd-internals] DMD now requires a working D compiler to be build
"Walter Bright" wrote in message news:mdjh6g$215p$1...@digitalmars.com... Not really. I never had to compile one one machine and copy the result onto another. It doesn't have to be cross-architecture to be a cross compiler. How easy it is to copy the files over would decide which method is more convenient. Besides, it is likely the vast majority of the work would be in the back end, which remains in C++. I guess that makes sense. It should be easier to apply a backend patch to two versions than it would be with a large frontend patch. Anyway, after the new platform is brought up, the original 2.067 still won't be able to target it and will therefore no longer be a suitable minimum host compiler version. This could be fixed by creating a point release for 2.067 that includes the new platform support, or by bumping the version requirement to the latest release. If we're talking months, then a point release is reasonable. If 2.067 is years old by then, it's probably best to bump the requirement. I think keeping the same minimum version the same for at least ~1 year should be reasonable.
Re: [dmd-internals] DMD now requires a working D compiler to be build
On 3/8/2015 9:07 PM, Jonathan M Davis via Digitalmars-d wrote: I thought that cross-compiling was pretty much always how you port a compiler to a new platform. Certainly, I don't see how we could require that ddmd forever compile with 2.067. The language is a lot more stable than it used to be, but it isn't _that_ stable. About once a week, when I pull all the DMD changes to my machine, it fails because it won't build druntime anymore. So I have to pull the druntime changes. Then it won't build Phobos anymore, so I have to pull that. And pray that it all will work, because sometimes it doesn't, and I don't know if the problem is in dmd, phobos, or druntime. This I want to avoid with bootstrapping the compiler. It's just too many things changing simultaneously.
Re: [dmd-internals] DMD now requires a working D compiler to be build
On 3/8/2015 8:43 PM, Daniel Murphy wrote: "Walter Bright" wrote in message news:mdj3l3$1hup$1...@digitalmars.com... Never needed to build a cross compiler. You did when adding 64-bit targets. ie dmd is a 32->64 and 64->32 cross compiler. Not really. I never had to compile one one machine and copy the result onto another. Anyway, in this situation: We want to target new platform X. Platform X has a c++ compiler but no D compiler available. 2.067 is the last version that can be built without a D compiler. DMD master can be built with 2.067 or later. The obvious (to me) way to get a working compiler on the platform is: 1. Add cross-compiling support targeting X to DMD master 2. Cross-compile DMD for X Or alternatively: 1. Add ability to target X to 2.067 C++ source 2. Compile 2.067 on X with C++ compiler 3. Add ability to target X to DMD master 4. Compile DMD master with native 2.067 dmd binary The second method is the only one I can think of that requires 2.067 can be compiled C++-only, and it also seems to require a lot more effort than the cross-compiling method. Which would you expect to use if adding support to dmd for eg arm/linux? Is there another method I'm missing? I think the only hard requirement is that there is a binary package available capable of targeting the platform, or the last C++ version can target it. For platforms that the C++ version has never supported, cross-compiling is the best option to produce the first set of native binaries. How easy it is to copy the files over would decide which method is more convenient. Besides, it is likely the vast majority of the work would be in the back end, which remains in C++.
