This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - JL235
1
« on: July 16, 2012, 03:37:18 pm »
1) Allow it to be restricted to a small number of calling IPs (Ex. I want logs for my sites, but I don't want some random person getting the source if he triggers an error). This could be done just by checking a text file with a list of IPs in it or such. (I'm actually not sure if you have this implemented or not, I haven't had a chance to use it yet)
It's not designed for use on live sites, instead for development only. However there are some features built in to help. For example you can run it from your php.ini file, allowing you to keep it out of projects. That way when you deploy your site, PHP Error stays on your dev machine. It also only runs if display_errors is on, and you can disable it in production. Information on setting it up from outside your projects can be found here, and the php.ini options can be seen here. Personally I favour that to IP filtering, as with most ISPs your IP changes on a regular basis. It also means if it's disabled for you, then it's disabled for everyone; there is no maybe middle ground. 2) Make your license a bit more prominent, it was a bit hard to track down.
Noted, I'll put the license into it's own file and check it in.
2
« on: July 13, 2012, 02:32:44 pm »
Error finders are awesome in static languages, because they are correct. In dynamic languages they often have to do a lot of guess work and prediction, or require you adding static type hints all over the place, in which case use a static language. I've also had JSLint be unable to parse large blocks of my JavaScript.
However syntax checkers are very useful, just to tell you if it will even compile or not, regardless of if there are any obvious bugs.
3
« on: July 12, 2012, 04:53:19 am »
It was mostly written in SublimeText2, but I've since moved back to gVim.
I also ran it through webstorm and send studio a few weeks ago, which caught two minor bugs. But tbh I wasn't very impressed with their error reporting, as I got 100s of non-errors reported too (mostly where they were just plain wrong).
4
« on: July 07, 2012, 08:02:09 pm »
Thanks, I'm glad people like it.
5
« on: July 06, 2012, 03:21:08 am »
About a month ago I finally decided enough was enough. PHP error errors just sucks, so I sat down and thought about building something I'd actually enjoy seeing. This is the result, PHP Error. It replaces the output with a fully syntax highlighted stack trace, with code snippets, and makes some error messages more meaningful. There is an example on the site, and it works for ajax requests too out of the box. I've found it surprisingly productive to use. I get errors fixed in 2 seconds instead of 10, and although that sounds minor, it helps to stop those long coding sessions from dragging. It's also designed to be trivial to import; just two lines at the start of your site, or you can import using your php.ini file, allowing you to keep it out of your projects. I do the latter, as it allows me to easily keep it out of a live site. There are instructions on usage via it's GitHub page. I hope others find it as useful as I do.
6
« on: January 08, 2012, 05:15:08 am »
My bad if it's not quite right, but my general point is that it's normally a two stage process. Working out the regex, and then working out how to get it working in the language. That second can trip you up sometimes.
7
« on: January 07, 2012, 02:44:05 pm »
I'm still not sure if your after 'omega' or '"omega"' (do you want to include the quotes?). If it's just 'omega', then the regex is just 'omega'. That means your looking for an o, followed by an m, followed by an e, followed by a g and then an a. In some languages you then have to format it in a special way, such as in JavaScript you add a / on either side, so it becomes /omega/. In PHP you do the same, and then put it inside a string, so it becomes "/omega/". Just be aware that the / wrapping is a convention used by languages to state that it's a regex, and not the regex it's self. As a result different language have different rules. If you want to use special characters, such as [, ., ^, /, \, $, * or +; then your right that you append a \ before it. However in some languages the \ already means something, such as "\n" is a new line in Java and PHP. So in those languages you have to escape the slash. For example the regex '\.omega' would become '\\.omega' in Java and (I think) PHP. If you state what language your working in, then more accurate help could be provided. There are also plenty of online regex testers available online, such as this one here.
8
« on: January 06, 2012, 01:07:29 pm »
and the paint editor I built for the site, has just been made a Chrome Experiment. Yay!
9
« on: December 23, 2011, 08:32:59 pm »
Is there a command for checking the color of a certian pixel? That would be useful, if there isn't one already.
There is, although indirectly. You can call the 'getScreenshot' function to get a copy of the screen as an image. On the Image object you can then call the 'getPixel' methods, or similar ones such as 'getPixelRed', to get specific pixels from the canvas.
10
« on: December 20, 2011, 08:47:26 pm »
For a travel mouse I essentially use this:  I got about 4 of them from my university, each with a different design, and they have each lasted years. They are also surprisingly good; I can happily use the mouse on any surface, with no issues, and it's one of the main reasons I use it. It's also dirt cheap, so if it does break after a few months, no worries.
11
« on: December 16, 2011, 11:17:01 am »
Just to throw it out there as an alternative, why not try a trackball? I have a Logitech Marble Mouse and it's excellent.  I've had it for 3 years now, and it's just as solid as one day one. I also play plenty of games with it, including FPS and strategy games, and it's fine.
12
« on: December 14, 2011, 10:31:09 am »
The problem with writing a new parser in Python, is that the implementations would probably end up drifting. New features and bug fixes would need to be built twice, and you would also find bugs in one implementation that are not present in the other.
I'd be more interested in re-writing in JS, as then it could be used for both desktop (using say V8 or Java/Rhino) and for the web. The compiler is also about 10,000 lines, which excludes the Quby libraries (String, Array, Hash, Function, Image, Controlls, Sound, etc), and I'd rather re-use as much as that as I could for any desktop port. The only bit that really needs re-building is the grammar, where the structure is formed.
13
« on: December 14, 2011, 08:26:07 am »
Quby is a very powerful programming language. Ever think about making a port of it for local use? (As in, ran on computer, not in internet browser.)
Yes, and I really want to re-write a huge chunk of the parser too (which will make pointing out syntax errors much easier). The problem is just a matter of finding the time.
14
« on: December 14, 2011, 07:36:38 am »
Good to know you got it fixed, although I take the feedback on board. It would have been better to have had a warning pointing it out (or at least suggesting it as a possibility).
15
« on: December 14, 2011, 05:47:24 am »
Are they errors with using it, or just bad debugging errors?
If have some examples then I can definitely work on them.
|
Show Posts