Hacker Newsnew | past | comments | ask | show | jobs | submit | Stormcaller's commentslogin

I had some minor "issues" after I installed ShellStatus and its dependency StatusMessage using package manager. These may be true for rest of the packages as well, luckily they are all 1-2 minute fixes at most, so they are just small quirks.

https://github.com/shagabutdinov/sublime-shell-status

The installation instruction said: "There is 'sublime-status' file in this package. Put it in your 'bin' folder..."

I put it in my bin folder, but it didn't read it. This was because on line 20 at shell_status.py, you -only- looked into package folder(and none of "bin") if the default wasn't changed. so unless I changed the settings and put some other name as my command, putting "shell-status" file in my bin folders wouldn't work, thus putting the default file in "bin" doesn't do any good. Just a mismatch between the documentation and code I suppose.

It also didn't create a ShellStatus/ folder under Packages/, which is the place you look for commands, so I had to create that as well.

There was also no entry for settings under "Package Settings", so I had to find the settings at Packages/User/ShellStatus.sublime-settings, it would've been better if I could go Prefences>Package Settings>ShellStatus like I can do with other packages.

Also the example on that page doesn't work, but again this is a minor detail too. There is no "<?php", so it just prints the file content itself. If you just add "<?php" after the comment it works. http://hastebin.com/ezirazekaf.php

I also have a request for anyone developing sublime plugins: I want to execute a shell command while I am working on the file, in-line. This is similar to some of your plugins, so I thought you may be interested. The output could be a comment. This would be useful when developing cli files, or just standard files if we can call it with "php arg1 arg2" or just "arg1 arg2" and have this file run with the correct path, get its output. Some plugins offer terminal access, but it is done in a separate/embedded window and the output is in console or a new file, and they offer no shortcuts to "just run the current file"

Anyways, thanks for the plugin. I will be using some of this.


Thank you very much for the detailed explanation of problems you had using this plugin. I converted it to issues and will fix soon: https://github.com/shagabutdinov/sublime-shell-status/issues. BTW, you can help me fixing it by open PRs.


It exists in other languages, too, like PHP.


You can do this in PHP, but you shouldn't.

Use (int), like C.


It is not much worse than using it in javascript. People do this in js because it saves a few keystrokes and its faster, not that it matters. Its a small thing. Its dirtier, for sure.

I just tested it in PHP and it seems it is 20% faster in PHP compared to casting to int. Maybe someone out there will have a weird use case for that, or someone doesn't want to put more effort into writing code into terminal and doesn't care about his code being unreadable. I think its useful to know it exists.

Btw, do you or someone else know why its faster in php too? Its a bitwise operation and I assume under the hood its casting to int, its weird to have it faster than casting it to int, why does this happen? It makes sense in javascript to that its faster than functions, but why it is faster than a cast in PHP?


> It is not much worse than using it in javascript.

It is worse because people are even less familiar with this in PHP. It's not idiomatic.

> I just tested it in PHP and it seems it is 20% faster in PHP compared to casting to int.

How rigorous was your testing? Which version of PHP were you using?

> It makes sense in javascript to that its faster than functions, but why it is faster than a cast in PHP?

It shouldn't be. It might save an allocation in older PHP versions, I'm not sure.


Its because they don't do the same thing

Math.floor() favors the number equal to/less than the parameter, Math.floor(-15.5) is -16 while (-15.5 | 0) is -15

Also because the returned value is int32[0],

Math.floor(2147483648.5) is 2147483648 while (2147483648.5 | 0) is -2147483648

You are fine if you know the input is less than (2^31) + 1 and you want to truncate, rather than floor.

[0]: http://www.ecma-international.org/ecma-262/6.0/#sec-binary-b...


ECMAScript 2016 adds Math.trunc()[0] which should give the same value as | 0 for inputs that fit in 32 bits.

[0] http://www.javascripture.com/Math#trunc


Hmm, pretty sure floor rounds a number downward to its nearest integer. So Math.floor(-15.5) would be 15.

https://developer.mozilla.org/pt-PT/docs/Web/JavaScript/Refe...


Literally the first example on that page:

> Math.floor( 45.95); // 45

> Math.floor(-45.95); // -46

Its not like its hidden or anything... Its in the center of the page on my 1920x1080 screen.


Nope. Math.floor(-15.5) would be -16. It rounds a number downwards. -16 < -15.


I wonder if there was an idea of a "strict mode" at any point? When making sure every site works surely you guys will have to render invalid code "correctly", I assume.

For example I am willing to develop in your browser if it meant I wouldn't broke some rules and the browser would care about that. Of course html validators exist and browsers display invalid css in their inspectors but I am asking for something like that would expect valid code. throw an error in my face if I didn't close a html tag or used an invalid css value, at any point.

Like if a javascript code resulted in my page getting invalid layout then browser could yell at me that causes an invalid layout. Maybe even a small performance improvement if my code conformed to every layout rule.


xhtml worked like that, html5 has moved towards specifying the quirks that are used to deal with poor conformance. That said, if you look at a webdev console, things that cause poor performance (à la document.write) tend to be noted.


Yes! A nice idea that... as has been previously mentioned XHTML failed due to there already being a version of the same thing with tonnes of automatic error handling built in! Which one will be most popular; a programming language that always seemed to complain and display an error, or one that 99% of the time corrected your mistakes for you.


Ok, I think this doesn't mean much and is a flawed experiment. The test url is: https://devx.lt/en/node/9 which contains ALL the content used in this experiment. All 9 tests are done on the same page, at once.

in the 4th experiment, he searches for "site:devx.lt GetJar is an independent mobile phone app store founded in Lithuania in..." and the result is returned WITHOUT any bold text. So this was a "most relevant" result, not a "found" case. Now the problem is, these paragraphs contain same words. Google returns "LinkedIn /ˌlɪŋkt.ˈɪn/ is a business-oriented social networking service. Founded in..." because, for one it at least contains "founded" part and further the paragraph I'm sure there is more. Since the results are limited to "site:divx.lt", and paragraphs contain same words, of course all 9 tests end with "found", as it is the only page close to being relevant.

I'd like to see the same test repeated, -NOT- all tests on the same page.

Some tests return bolded results, so I consider them to be true. I think 1-2-4-5 are false positives.


We also can't be sure that "literal searches in quotes" are considered the same way for SERP ranking etc, which I guess would be the motive for hiding text.


also these text contain double-quotes so I wouldn't be surprised if they aren't even considered

few examples:

Its mission statement from the outset was "to organize the world's information and make it universally accessible and useful,"

140-character messages called "tweets"

LinkedIn filed for an initial public offering in January 2011 and traded its first shares on May 19, 2011, under the NYSE symbol "LNKD"


I'm not sure how much views get lost, but I wonder is it worth it? There is a short video as introduction which doesn't tell much, I'd much prefer a random video from the series.

Now by making these private, no one will find this from youtube, other sites won't link it and there is no playlist so I will have to click each url every 5 minutes or so, which is not the end of the world, but not fun.

He could have asked for my email for the project files(videos and project files get sent to your email currently as I understand it), and gave videos for free. Anyone actually interested in this would definitely give their email for the files. If he wants my email to teach me something else later -- or sell me something, I think someone who entered their mail while watching the series will be more interested in what he could use the emails for, and now he won't be able to reach these kinds of people from random views, in exchange for the initial email count.

I don't think this is a nice deal, but I have no data, so just an opinion. Maybe something to consider.


Valid points but having an email is much better to stay in touch in the future. If you don't like that - use mailinator- totally understandable

I'll publish the playlist in a week but for now I'm doing it only on the site.


Because max value should be "mt_getrandmax()" instead of "PHP_INT_MAX", it just gets a 32 bit number then scales it up.

see: http://php.net/manual/en/function.mt-rand.php

Under caution:

The distribution of mt_rand() return values is biased towards even numbers on 64-bit builds of PHP when max is beyond 2^32. This is because if max is greater than the value returned by mt_getrandmax(), the output of the random number generator must be scaled up.

edit: this post went from 5 points to 1, which I don't care about(in ~500 days I posted less than 10 times and I have ~35 points), but who downvotes documentation, seriously? -_-


While documented, that is surprising behavior. If it takes in an int, shouldn't it be able to take in PHP_INT_MAX? And shouldn't it yell at you instead of just silently going about its day?


The PHP approach seems to be that any crazy behavior is acceptable as long as it's documented.


To be fair, that is not an uncommon situation elsewhere either.


I think it is. Sure, there are plenty of calls out there in all sorts of systems that have crazy, documented behavior. But it's rare to see anyone outside of the PHP world defending the crazy behavior purely on the basis that it's documented. Crazy behavior is almost always there because of compatibility concerns, performance concerns, or an acknowledged bug that just hasn't been fixed yet. Outside of PHP, I rarely see anyone just say, "It's fine, that's how it's documented to behave" and leave it at that.


I recall a Rails bug used to hack github and inject a bugfix commit. The Rails community rejected the fix originally because the crazy behavior was documented.


Wow. Do you have any more info on this?



Outside of php and systemd.....

<Friday afternoon trolling is just too easy this week />


And mySQL of old.

I assume things are much better now, but I remember a time when things like INSERT <table> (<date_field>) VALUES ('2015-02-30') would not have raised any sort of error, amongst other terrible things that people would defend having to implement explicit checks for in other layers of your application.


> I assume things are much better now

Nope: http://grimoire.ca/mysql/choose-something-else


I'm genuinely curious, what are some examples of systemd's odd behavior?


Well, the fact my window manager is now intrinsically linked to my systems boot process strikes me as somewhat obscene. There was the amusement with it reacting to debug being passed to the kernel which caused the system to never finish booting...

systemd is by no means alone; in the last month I've discovered that `yum` deliberately breaks its output when you try and pipe it to something else (I mean really, ffs, really?). The justification for this isn't even internally consistent which really winds me up too...

Whilst I pick on a couple, there's been innumerable packages, languages and platforms over the years that have had their share of what could politely be called idiosyncrasies. I highly recommend The Unix Haters Handbook [1] for plenty of historic examples -it's a lovely read -oh, and for years one of the *nix bullet points was always "all the power in the world and not a safety in sight" [2]

[1] The Unix Haters Handbook: https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook || http://www.csf.ac.at/fileadmin/user_upload/BioComp/training/...

[2] The Hole Hawg: https://web.archive.org/web/20150214132948/http://www.team.n...


> Well, the fact my window manager is now intrinsically linked to my systems boot process strikes me as somewhat obscene.

Gnome depends on logind, which is sensible. Yes, logind is part of a suite of system management tools which also includes tools to manage the boot process.

Your complaint would apply equally to your window manager being intrinsically linked to your serial port (via the Linux kernel).


Not just part of, logind will straight up not work if systemd is not running as pid1. As such, anything that depends on logind is dependent on a specific init sitting as pid1.


As an honest question, could you explain _why_ it's sensible?

Until a couple of years ago, my linux box was nearly entirely modular letting me install any combination of boot-loader, kernel, init system userland tools and/or desktop. How is this better?


What's more common outside PHP is that functions throw errors or exceptions when given invalid input, rather that trucking along and producing output that is clearly not what was intended.


Maybe they should just make the random functions return '4', documenting that it was chosen by a fair dice roll and is therefore guaranteed to be random.


That's not a "crazy behavior", it's a limitation of the algorithm they use. mt_rand() only has approx. 2^32 possible seeds; why would you expect it to support ranges larger than 2^32?

The best thing to do is to not use mt_rand().


> why would you expect it to support ranges larger than 2^32?

Because this is not a simple, stupid linear congruential generator. mt_rand(), is, as I understand it, based on Mersenne Twister, a well-regarded generator which has a period of 2^19937. And if PHP had done this right, mt_rand() would be seedable with an array of some 624 integers.

Mersenne Twister has an alternative "classic" seeding algorithm, drawn from Knuth, to be compatible with old-style generators. This algorithm takes a 32-bit seed. Apparently that's all that PHP is supplying.

It's dead simple to do random(n) uniformly. When I heard that some language implemented a function called mt_rand() which was hilariously broken in this respect, the first thing that came to my mind was "that's gotta be PHP". And it was.


I would not expect it to support ranges larger than 2^32, so why does it?

Returning garbage when one of your parameters is beyond a certain limit is "crazy behavior." Either support it properly, or don't support it at all.


If we were talking about C this would be called undefined behavior. If you don't satisfy the preconditions before calling a function then the not only is the output invalid but the entire program which uses it is invalid too.

I don't think a language like PHP, or indeed anything written in it, should have undefined behavior but I'm not the author of the library.


"Fixing" broken data silently is tremendously bad behaviour in general because you can't possibly know whether the caller knew that they were providing invalid data and whether the caller is going to be happy with your fix.

If you expect input parameters in some range and you get values out of that range, then you blow up. You don't silently truncate anything and you certainly don't reduce the entropy of your random number generator by nearly 50%.


This was my main doubt about PHP 7's scalar types, which will autocast values into the desired types. I don't expect the caller to know better than the callee what are the method's boundaries, and once casted you may not be able to see if the input was garbage. But yeah, when something breaks the method's author can wash their hands.


If the user asked for more bits of randomness, they need to generate more bits. They could have chosen a different algorithm, or perhaps called the random number generator twice and concatenated the bits. Scaling up is clearly the wrong thing to do.


It also makes me wonder how it behaves for numbers below the limit. I would wager that there's substantial bias in the results if you ask for a max of, say, 2^31 + 2^30.


The crazy part is that, instead of throwing an error when given input that doesn't make sense, it just silently produces garbage output.


This. Documenting odd behavior like this isn't an excuse for having odd behavior. It should just be changed to fail on bad input. It's not even a breaking change (apart from code already using it with bad input).


How else is it going to unseat INTERCAL?


First it needs a replacement for INTERCAL's "please come from".


If it's documented it's a feature.



A clear example of "worse is better" winning.


Almost everything in PHP is surprising behavior.

And yes, in the eleventy billion cases where PHP should yell at you that it's doing something totally different than what you wanted, it instead just goes about its day silently.


Which is why it was a great fit for MySQL, which would silently store invalid dates and truncate over-long strings with no warnings.


You joke, but I'm pretty sure this is one of the reasons why that stack was so successful. Same principle behind HTML rendering. "It's displaying something, isn't it? Errors are only suggestions."


I'm not so sure. It's kind of true for HTML (forgiveness was not "good" property of the format, but of the browser: 1 site works in one browser, but not in the other, and user will blame the browser, so let's display whatever the hell we can). But PHP in the early days was kinda handy (even though hacky) tool, allowing to use simple syntax to render HTML instead of custom Perl-scripts. And then it just got popular.

MySQL was once actually superior open-source database, being more performant and simpler to setup and use than PostgreSQL. And then, once again, it just got popular.

I don't think being faulty helped these technologies, although it sometimes is the case.


There are warnings. Most people just ignore them in their APIs


Trying to insert over-large data should have been an error by default from the outset, never a warning. Ilooked at MySQL in 2000 and went "You had one job, database; protect my data."


This is so true. It is the main reason I switched to PostgreSQL and never looked back.


... and accept nonsensical SQL queries, returning whatever it feels like.


>Almost everything in PHP is surprising behavior.

It's not. White it does have several surprising behaviors, "almost everything" is just an example of uniformed BS people say when it comes to PHP.

C also has undefined behavior and several bad decisions, ditto for C++, Javascript, etc. But PHP is just an easy target for trolls.


Even worse, some of the Internals teams argue in favor of silently trucking along instead of, e.g. throwing an exception: http://www.serverphorums.com/read.php?7,1250372

EDIT: because of HN's annoying "you are posting too fast" limit I cannot reply to the comment below.

The arguments against Exceptions began in the comments on the relevant pull request: https://github.com/php/php-src/pull/1397


from that thread..

   At what point do we stop blaming the developers for not knowing how to
   use our badly designed features, and accept responsibility for exposing
   an API that is hostile towards simple, efficient, and correct implementations?


It might be worth noting that 'sarciszewski was the author of that remark.


Actually that thread seems to strongly argue that either an Exception or fatal error should be thrown. I'm not seeing anyone in that thread wanting to silently truck along -- am I missing it?


Wow, that thread is current! This mentality really is systemic to PHP. It's like the exact opposite of "let it crash".


That is not the PHP way.


[deleted]


    php > echo PHP_INT_MAX;
    9223372036854775807


the error is from php 4.2 or something.


Ah, I see, I just misunderstood their interface. Thanks.


There is a caution box in the description, which contains a different warning, and then the warning you have cited is in a second caution box in the "Notes" section, after the changelog and the examples.

It doesn't surprise me that people might not notice the existence of that second warning. I believe that most developers wouldn't scroll down to read the changelog and the example if they think they understood what the function does from its description.


Why even accept ranges that span more than 2^32? That seems like an easy solution to a broken function.

Also fun:

    echo "<?php echo mt_rand(-mt_getrandmax(), mt_getrandmax());" | php
is always even on my PHP 5.5.20.


> Why even accept ranges that span more than 2^32? That seems like an easy solution to a broken function.

It may never have been designed to. If it was written before 64-bit machines were commonplace, mt_getrandmax() would always be the same as PHP_INT_MAX.


Why not generate two values from the underlying function and shift them into place if the range is larger than 2^32 -1?

Oh well, ofc. because this is PHP which goes by the principle of most surprise.


Yes, that's exactly what sensible RNG interfaces do, like std::random in C++. If your underlying engine only produces 32 bits at a time, it'll grab two of them when you request a 64-bit type.


no surprised about the down votes, i've seen a lot of logical explanations and correct responses get them. its almost like they would rather read drama then thoughtful answers.


> Because max value should be "mt_getrandmax()" instead of "PHP_INT_MAX", it just gets a 32 bit number then scales it up.

How does that answer anything?


<font>, I don't think there's an excuse. we know for sure that it is not out of incompetence but it was probably easier to write at the time and nobody bothered to fix it because it doesn't really matter.

For the <center>, it is probably not the case here as this is just a text based site but sometimes it is easier to center an image by that tag when your site is partitioned in many margins it is not as easy to center some stuff, or you might just prefer to add a tag.

I also like <br>, it really makes more sense to me and easier to write. It doesn't really break anything either.

I wonder how many there are, like me, think that <center> and <br> are actually really nice things to have?


There's nothing wrong with font tags on HN. You might not realize that the pages served on this site are machine-generated!


I agree. Its just they could add a class to css, and instead of setting font tag to each element, just add the class. But of course, since they are generated in a loop anyway, there's no practical difference.


Not many but they're deprecated/obsolete for a reason, don't you think?


Perhaps not many in the design community or front end devs, but I'd wager there are plenty of developers who love <br> because it's what they've always used to do simple layouts so they can get back to the back end.


br is neither deprecated nor obsolete


HECK YEE! I even put classes in my <br> tags so I can get at them and decide when and how they display!


HECK YES! I even put classes in my <br> tags so I can get at them and decide when and how they display!


you'd lose the case, on the left it says "stable when pushing"


Well the data sent is "window.innerHeight" so if 1920x1080 is a popular screen resolution, some people will be using windows XP which will have 30 px taskbar size, and some people will be using 40 px taskbars with windows 7. Then some people will have browsers "not maximized" so they will be missing a few pixels too, and so on.

So from single height value, we have many variations differing by few pixels. Then, I think, we can gather some popularity info from this, if there is many variation around 1080 and less around 1200, this would mean the former is more popular.

So we don't need devices with different sizes but just a few different software choices.

or so I think.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: