I'm very VERY confused!!
var_dump('12345678901234567891' == '12345678901234567890');
shows bool(true)!
I know about "===" but in this example two strings (types are same)!!!
Moreover strings are consists only of DIGITS!
Any suggestions?
That appears to be a < php 5.4.4 issue. Try running your code in php 5.4.0 and then try 5.4.4 or greater and you will notice you get different results. To test try an online php sandbox such as http://sandbox.onlinephpfunctions.com/
Also that's a rather old version of php, maybe seeing if it can be upgraded might be a good thing?
Edit: Using === seems to work on older versions of php as you would expect so you should probably use that instead.
Related
I am in the process of porting a legacy (CS5) Photoshop plugin for macOS written in C++ to current technology (Photoshop 2022, macOS 12.4).
I’m currently struggling with the fact that CFURLCreateFromFSRef is deprecated and should not be used any longer. Now, thanks to the newest version of the Plugins Suite, that shouldn’t be a problem, SPXPlatPluginsSuite should return an XPlatFileSpec, which gives the file location as a CFURLRef.
Unfortunately, if I acquire the suite with kSPPluginsSuite and kSPPluginsSuiteVersion6, then call GetPluginXplatFileSpec, the resulting XPlatFileSpec.mFileReference is null, the mFileSpecVersion is 0.
If I use kSPPluginsSuiteVersion4 for the Suite acquisition, then call GetPluginFileSpecification, the resulting SPPlatformFileSpecification.mReference contains the correct (but useless) FSRef.
What am I doing wrong here?
Found a way to do it:
Stick with kSPPluginsSuiteVersion4 and GetPluginFileSpecification, then use PSGetPathSuite1 to get the path out of the returned SPPlatformFileSpecification as a string. From there I can create the URL as needed.
Was amphp/thread discontinued? amphp/amp is working perfectly but when I run ANY of the example coding from amphp/thread git, I get all kinds of errors. Not one example is working. I noticed last update was in 2014.
Is there any way for me to get amphp/thread working? Was it replaced? With what replacement?
I have php 7.0 installed on mac, built with thread safety. EV, EVENT, UV are all enabled.
My .jason file looks like this
"amphp/amp": "v0.17.0", "amphp/thread": "v0.8.1"
Much appreciated.
I found the answer to this question in a discussion here:
https://github.com/amphp/thread/issues/14
amphp/thread is no longer being supported but there is hope that it will be picked up again in the future to work with amphp/amp v2. No concrete timeline on when this will happen was given.
Also, amphp/parallel is considered to be the replacement for amphp/thread.
When converting a thrift object for nodejs:
thrift -r --gen js:node state_service.thrift
The following error is thrown:
[ERROR: /state_service.thrift:33] (last token was 'not') Cannot use
reserved language keyword: "not"
The lines in the code around 33 are:
typedef bool Not
struct Exp {
1: string left
2: Not not
3: BinaryOp op
4: AnyValue right
}
I am using the most recent Thrift version 0.9.2
Try to change the not to something else, i think the problem is that 'not' may have another meaning in the language that you choose to generate.
2: Not not
The solution is to not use the reserved language keyword, as advised by the Thrift compiler. These keywords are reserved for a reason. Thrift is a cross-language tool, and not is indeed a keyword in some of them.
I don't want to change the processing code only because of a faulty js converter.
I beg to differ. Faulty is something that does not work, altough it should. Thrift clearly tells you that what you are about to try is illegal (as of today) and what the problem is.
To put it another way: With Linux, you can put uppercase and lowercase letters in a file name (actually you can put a whole bunch of strange things in, but I'll make it easy). So creating a FILE and a file in the same folder will work perfectly. If you now take your program and run it on Windows, relying on that behaviour, you will sooner or later run into trouble and may start to complain you "dont want to change your processing code only because of that faulty OS".
Note that complaining will not help you out of the pothole, altough the endorphines emitted during that process will make sure you have a fun time. The solution is of course to wait until Microsoft fixed their faulty OS, because you make the rules. Correct?
Of course not. So if you feel the implementation is wrong - fine! This is Open Source, and nobody claimed perfection. You are free to provide a patch, and we will happily review it. But please make sure you tested it with all 20+ languages currently supported by Thrift.
Is there a FormAlchemy alternative for Python3.2? I'm specifically interested in using it in conjunction with Pyramid.
I'm getting syntax errors when setting up FormAlchemy1.3.3 so their latest release is not compatible.
At time of writing there is none
I'm working on a side project that involves sorting Japanese and Thai strings. When I was testing the sorting in client-side Javascript, I was able to use a.localeCompare(b, "languageCode") which worked. When I tried this same logic in Node, it did not work, because the Node INTL object is restricted to English as the default.
I want to customize my node build as described in the above link, and came across the ICU4C-data Node Module, which I understand contains a full set of ICU data. I've been playing around with different build flags, like the one specified by the (sparse) README: --icu-data-dir=node_modules/icu4c-data, to no avail - no matter which flags I set I cannot get the INTL Collator's compare function to give the expected results. Is there an obvious flag that I'm missing, or key assumption I have wrong?
Here are a few things important notes/resources:
The end goal is Thai & Japanese collation - if there's another approach using Node to implement this, I'm open to suggestions.
Collation must be done in Node
I'm going to be relying on Array.prototype.sort() - mainly looking for a comparator
Using Node 0.12, with ECMA support
My first time customizing a Node build (~1 month experience)
Install the full-icu package instead. It will give instructions on how to load the rest of the data.
Also note that future node versions should not require any configuration to pick up the new data, you can see #3460 if interested.
I need to fix the icu4c-data's readme to reflect this.