PHP meets GTK, want to meet WTF
-
Continuing the discussion from "Jump, Apple". "How high, ancarda?":
Eh, I wouldn't call it that much, but in this case, nothing PHP-GTK ever made the internets.
I could give it a go some time if people here are curious to see what the worst that could happen is...
So far a Discourse "native" client and a NodeBB "native" client have been suggested. Am curious what levels more of we could perpetrate.
Poll will be forthcoming when more suggestions have been made.
-
Why not a native client that can render HTML and CSS and supports JavaScript? We don't seem to have any of those yet. Could you imagine using Discourse in such a native client?
-
In PHP? What's the worst that could happen?
-
I bet text editor in PHP-GTK would at least be able to support more than 2MB of text at once.
-
Probably consuming about 512MB of RAM to handle it, but I'll put it on the list :)
-
-
We could have an AI to play Mario games.
-
I thought we established we weren't building SkyNet?
-
How about a grand strategy game?
-
The only winning move is not to play.
Though I could prototype the thing I've been thinking about doing in it...
-
-
I remember playing around with PHP-GTK. I think I tried writing a control program for my IRC bot (which basically turned into an IRC client).
-
You know, that big guy with the rocklike skin? Everyone hates any movie he's in?
-
Why not a native client that can render HTML and CSS and supports JavaScript? We don't seem to have any of those yet. Could you imagine using Discourse in such a native client?
That's a reverse JavaScript roadmap. Instead of client-side language also gets used on the server, do you really want to help making a server-side language being used on the client?
Filed under: <script type="text/php">, what could go wrong?
-
We could have an AI to play Mario games.
Unsurprisingly, that's already being done:
https://what.thedailywtf.com/t/super-mariux-and-an-untold-story-yet-to-be-written/54471/
-
Why do you think I said that? XD
-
Make an advanced Brainfuck IDE.
A language like that deserves to be used for esoteric language development.
-
Surprised no one said "Explorer replacement" especially as elsewhere there was discussion about Total Commander, dual pane support etc.
-
Hey, how about a dual-pane Explorer replacement?
-
Map the panes to faces of a platonic solid so that switching between them can be done by rotating the surface. Bonus points if you make the code so that it insists on using more than 6 sides and accidentally flips to other sides from time to time (triggering motion sickness in the average developer).
-
-
So... Place your votes now!
[poll]
- native Discourse client
- native NodeBB client
- browser with full DOM and JS support (might take a while)
- text editor
- Arantor PHPShop CS 6
- grand strategy game
- Brainfuck VM+IDE
- dual pane Explorer replacement
[/poll]
If the above happens, it'll likely end up on GitHub with a caveat of "done knowingly to see how insane this will get"
-
Me and @Arantor already agreed PHPShop will be written in pure PHP. I'm not letting him shell out to ImageMagick or GD after he wrote his own EXIF parser in PHP.
You'll have to make due with PHP's fantastic binary handling.
-
There is a "if this happens" as it is subject to time, energy and sanity. But also, if we're talking "no external libraries", that means image handling by storing images in strings as the least retarded way of doing this in PHP as arrays of arrays will munch through memory at a ferocious rate.
-
-
What is the difference between a blob of binary data and a string? Think carefully before trying to answer this.
Ready to go on yet?
Essentially nothing. Binary data is a sequence of symbols chosen from the alphabet of numbers from 0 to 255. That's _very_ cromulent with the concept of strings (which nowadays support an even larger range of characters). You might be using a somewhat different set of operations on the data within it, but there's really not much actual difference.PHP might make this more awkward. ;)
-
Note: I said brainfuck IDE, but it could be any esoteric language. Brainfuck is a bit overdone IMO.
-
Yeah. If it's graphical, it should be for Befunge.
-
BIT?
<valid post>
-
He said esoteric, not "only used by a single developer"... ;)
-
I'm ok with Befunge. Why not both?
-
15 votes so far with unexpected results. I'll give it tonight to see precisely what results.
Also, it's my topic and I'll reply to as many people individually as I fucking want.
-
-
Oo oh it's a tie. Going to leave it open to the morning to see if there's an answer.
-
Clearly grand strategy phpshop
-
-
Seriously tempted to go with the grand strategy game one, actually. I've had ideas for one for a while and never had the balls to even try prototyping let alone implementing it.
-
After 23 votes, the results are in and "grand strategy game" has won it!
More details will be posted if I can get PHP-GTK to actually work...
-
-
What's that in the bottom right corner?
-
He's just happy to see you!
-
Just for the record on the whole image-as-string thing, @dkf is pretty much spot on, as in PHP terms a string is just a byte array pretending to be a scalar primitive type, but it really is a byte array with fudges.
Specifically, behaviour of array functions on strings is technically a cause for erroring, but depends on a bunch of circumstances.
You can, in more recent PHP versions even have array addressing, e.g.
$mystr = "String"; echo $mystr[0]; // outputs "S"
PHP doesn't exactly get Unicode which is why you have to remember to use the
mb_
functions if you want characters and things likestrlen
if you don't care or want binary explicitly.Unless you have one of those fucktarded hosts that sets up the
mb_
functions to automatically overload onto the non mb functions to "help".As far as using arrays goes, the internal struct that holds a PHP variable - a zval - typically carries 10+ bytes per instance overhead last I looked at the Zend internals, could well be more now, so if you had a 100x100 image with an array of RGBA items per pixel, you could easily be looking at 1.6MB memory use for that versus a shade over 40KB for the string version and it likely would be faster in the string too. Even in PHP.
I will talk about the game plans in another thread where I can talk about what I had in mind to prototype that @royal_poet is not so subtly kicking my arse to work on...
-
You can, in more recent PHP versions even have array addressing
Recent? Pretty sure that's ancient.
Anyway, on the size front, don't forget 56 bytes per array element in addition to the zval contained in it.
-
Older versions used
$var{0}
syntax even outside of double quotes. I think with 5.3 they finally decide they didn't want that.Is it 56 bytes overhead? I didn't think the overhead was still that large with the changes in 5.4 and 5.5 but as I mentioned, it's been a while since I looked at the innards of the Zend engine.
-
Was 56 bytes back when I checked, on 64-bit. Probably 5.2 or something. pointers for prev/next in order, prev/next in hash bucket, key (string), and value (zval), plus another 8 bytes for the hash. You could reduce that to 40 bytes by eliminating the prev pointers at some cost. You might be able to inline the value zval, but then you can't pass references to pointers to zval anymore.
As a zval is basically a tagged union; could be done in as few as 9 bytes but is probably 16 bytes because of alignment.
-
It has been a while indeed, but I rather suspect you're right about this.
I don't generally have to get into the innards of PHP for any reason ;)
-
Older versions used
$var{0}
syntax even outside of double quotes. I think with 5.3 they finally decide they didn't want that.if I remember my history correctly (started PHP in 2001, but I haven't used it much since 2010), it was originally $str[0], then it was changed to $str{0} to try to convince people not to think of strings as just arrays of characters, then $str{0} was dropped because nobody switched to it.
As someone who generally prefers strong typing, I actually like $str{0}, since you would get an error message when you try to use a string as an array instead of some unexpected value caused by several type coercions.
-
If they wanted wide adoption they should have called it something like
$str[]_real_{0}
-
I don't go that far back. But I do remember the whole {0} thing, though in later versions of PHP they've kind of stopped pretending that strings aren't just byte arrays.
I tend not to reference them like that just on principle, doesn't come up that often for me.
-
I took the screenshot from YouTube; it's the channel picture of The IT Crowd