Talk:ERR GENERIC - Revision history

Strife Onizuka: /* Hex vs Decimal */

2014-01-05T05:44:44Z

Hex vs Decimal

← Older revision		Revision as of 22:44, 4 January 2014
Line 8:		Line 8:

	:::Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was [[Release_Notes/Second_Life_RC_BlueSteel/13#13.06.06.277104\|non-existent]]. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in {{JIRA\|BUG-4703}} about [http://en.wikipedia.org/wiki/Year_2038_problem Year 2038 problem] "Scheduled for sprint-summer'''2027'''". Anyway, how do we want to move forward? -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 21:01, 4 January 2014 (PST)		:::Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was [[Release_Notes/Second_Life_RC_BlueSteel/13#13.06.06.277104\|non-existent]]. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in {{JIRA\|BUG-4703}} about [http://en.wikipedia.org/wiki/Year_2038_problem Year 2038 problem] "Scheduled for sprint-summer'''2027'''". Anyway, how do we want to move forward? -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 21:01, 4 January 2014 (PST)
			:::Everything about ERR_GENERIC was editorial whim (I think I was channeling Zork). If you look at the names of the [[Template:LSL_Constants/ReturnError\|ERR constants]] you would agree, there is nothing about them that says "Use only with llReturnObjects* functions" they are all pretty generic names, the closest you get is [[ERR_PARCEL_PERMISSIONS]] and if they were to only be used with them, you would expect them to be named ORC_* or something like that. And -1 is a pretty generic error code in most APIs, it usually means, "what you wanted done failed to go the way you planned" and doesn't that describe what happens when you tell LSL to find a string in a string, or a list in a list? -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 21:44, 4 January 2014 (PST)

Strife Onizuka: /* Hex vs Decimal */ Only constant names and values were listed in release notes.

2014-01-05T05:35:17Z

Hex vs Decimal: Only constant names and values were listed in release notes.

← Older revision		Revision as of 22:35, 4 January 2014
Line 7:		Line 7:
	::Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). [[User:Omei Qunhua\|Omei Qunhua]] 04:39, 4 January 2014 (PST)		::Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). [[User:Omei Qunhua\|Omei Qunhua]] 04:39, 4 January 2014 (PST)

	:::Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was non-existent. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in {{JIRA\|BUG-4703}} about [http://en.wikipedia.org/wiki/Year_2038_problem Year 2038 problem] "Scheduled for sprint-summer'''2027'''". Anyway, how do we want to move forward? -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 21:01, 4 January 2014 (PST)		:::Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was [[Release_Notes/Second_Life_RC_BlueSteel/13#13.06.06.277104\|non-existent]]. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in {{JIRA\|BUG-4703}} about [http://en.wikipedia.org/wiki/Year_2038_problem Year 2038 problem] "Scheduled for sprint-summer'''2027'''". Anyway, how do we want to move forward? -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 21:01, 4 January 2014 (PST)

Strife Onizuka: /* Hex vs Decimal */

2014-01-05T05:01:10Z

Hex vs Decimal

← Older revision		Revision as of 22:01, 4 January 2014
Line 6:		Line 6:

	::Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). [[User:Omei Qunhua\|Omei Qunhua]] 04:39, 4 January 2014 (PST)		::Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). [[User:Omei Qunhua\|Omei Qunhua]] 04:39, 4 January 2014 (PST)

			:::Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was non-existent. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in {{JIRA\|BUG-4703}} about [http://en.wikipedia.org/wiki/Year_2038_problem Year 2038 problem] "Scheduled for sprint-summer'''2027'''". Anyway, how do we want to move forward? -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 21:01, 4 January 2014 (PST)

Omei Qunhua: Misuse of ERR_GENERIC

2014-01-04T12:39:59Z

Misuse of ERR_GENERIC

← Older revision		Revision as of 05:39, 4 January 2014
Line 4:		Line 4:

	: This one is not supposed to be a flag, it was for [[llReturnObjectsByID]] and [[llReturnObjectsByOwner]], part of a sequence. The string and list index usage appears to have been editorial whim on the wiki, working by coincidence. --[[User:ObviousAltIsObvious Resident\|ObviousAltIsObvious Resident]] 10:43, 3 January 2014 (PST)		: This one is not supposed to be a flag, it was for [[llReturnObjectsByID]] and [[llReturnObjectsByOwner]], part of a sequence. The string and list index usage appears to have been editorial whim on the wiki, working by coincidence. --[[User:ObviousAltIsObvious Resident\|ObviousAltIsObvious Resident]] 10:43, 3 January 2014 (PST)

			::Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). [[User:Omei Qunhua\|Omei Qunhua]] 04:39, 4 January 2014 (PST)

ObviousAltIsObvious Resident: /* Hex vs Decimal */

2014-01-03T18:43:09Z

Hex vs Decimal

← Older revision		Revision as of 11:43, 3 January 2014
Line 2:		Line 2:

	Oh! Do people who come to the wiki for help understand 0xFFFFFFFF better than -1? Have we lost the plot? Will all these constants be changed when LSL moves to a 64-bit VM? Mind you, 0xFFFFFFFFFFFFFFFF would be a bit of a mouthful [[User:Omei Qunhua\|Omei Qunhua]] 02:33, 3 January 2014 (PST)		Oh! Do people who come to the wiki for help understand 0xFFFFFFFF better than -1? Have we lost the plot? Will all these constants be changed when LSL moves to a 64-bit VM? Mind you, 0xFFFFFFFFFFFFFFFF would be a bit of a mouthful [[User:Omei Qunhua\|Omei Qunhua]] 02:33, 3 January 2014 (PST)

			: This one is not supposed to be a flag, it was for [[llReturnObjectsByID]] and [[llReturnObjectsByOwner]], part of a sequence. The string and list index usage appears to have been editorial whim on the wiki, working by coincidence. --[[User:ObviousAltIsObvious Resident\|ObviousAltIsObvious Resident]] 10:43, 3 January 2014 (PST)

Omei Qunhua: /* Hex vs Decimal */

2014-01-03T10:36:01Z

Hex vs Decimal

← Older revision		Revision as of 03:36, 3 January 2014
Line 1:		Line 1:
	== Hex vs Decimal ==		== Hex vs Decimal ==

	Oh! Do people who come to the wiki for help understand ~~0x7FFFFFFF~~ better than -1? Have we lost the plot? Will all these constants be changed when LSL moves to a 64-bit VM? Mind you, ~~0x7FFFFFFFFFFFFFFF~~ would be a bit of a mouthful [[User:Omei Qunhua\|Omei Qunhua]] 02:33, 3 January 2014 (PST)		Oh! Do people who come to the wiki for help understand 0xFFFFFFFF better than -1? Have we lost the plot? Will all these constants be changed when LSL moves to a 64-bit VM? Mind you, 0xFFFFFFFFFFFFFFFF would be a bit of a mouthful [[User:Omei Qunhua\|Omei Qunhua]] 02:33, 3 January 2014 (PST)

Omei Qunhua: Hex vs Decimal

2014-01-03T10:33:43Z

Hex vs Decimal

New page

== Hex vs Decimal ==

Oh! Do people who come to the wiki for help understand 0x7FFFFFFF better than -1? Have we lost the plot? Will all these constants be changed when LSL moves to a 64-bit VM? Mind you, 0x7FFFFFFFFFFFFFFF would be a bit of a mouthful [[User:Omei Qunhua|Omei Qunhua]] 02:33, 3 January 2014 (PST)