How do I compile a new function created inside a package in plsql, to see syntactical error and so on
You can't compile a single function - compile the whole package.
If your concern is about invalidating the whole package in case that function has errors, then
create a standalone function (i.e. outside of the package)
debug it
once it is OK (doesn't have syntax errors, returns result as expected), include it into the package
In addition to #Littefoot's advise I'd say: use a proper GUI. Oracle has a free tool called sql developer. It has a great interface for editing database objects (packages/functions/procedures/triggers). It highlights errors and is very well documented (https://www.thatjeffsmith.com/sql-developer/). Note that is does not point out syntax errors - but once you're a bit used to working with pl/sql they become obvious very quickly.
In Oracle, after compiling a procedure/function/package. If there is an error then the command will return with the message:
ORA-24344: success with compilation error
You can then use:
SHOW ERRORS
or
SELECT * FROM USER_ERRORS;
or, for example, for errors with packages in a specific schema:
SELECT *
FROM ALL_ERRORS
WHERE owner = 'SCHEMA_NAME'
AND type IN ( 'PACKAGE', 'PACKAGE BODY');
Which will list the errors (complete with line numbers and error messages) and you can then debug the procedure/function/package and recompile it.
fiddle
I get a window ID from the command line, and create an SDL window with it:
Window window_id = from_cli(); // e.g. 0x34000c8
w = SDL_CreateWindowFrom((void*) (Window) window_id);
When my program finishes I try to clean up:
SDL_DestroyWindow(w);
And that is when I got an X11 error:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x34000c8
Serial number of failed request: 255
Current serial number in output stream: 256
Obviously, the caller of my program - which I cannot change - has already destroyed the X window I was using.
How should I handle this situation?
SDL_DestroyWindow() can be omitted if the SDL window was created with SDL_CreateWindowFrom()
go for SDL_SysWMinfo, pick up x11.display, create my own X11 error handler, and filter errors for window_id?
Looking at the SDL2-2.0.9 source code, it seems that SDL already sets an error handler, which calls the previous error handler, which is the default one that terminates the program on error. (src/video/x11/SDL_x11video.c::X11_SafetyNetErrHandler())
Internally SDL will override this error handler temporarily, when doing its own stuff. (src/video/x11/SDL_x11video.c::X11_CheckWindowManager())
Thus, I guess 2) is the correct way to go.
EDIT:
When omitting SDL_DestroyWindow(), SDL_Quit() will fail with the same X error.
I also realized that SDL may not anticipate a failed X call, so ignoring the error may not be a good idea, after all.
EDIT2:
I just realized that SetErrorHandler() does not require a display.
Adding an X error handler that ignores X errors regarding this particular X window seems to work, not sure if it creates new problems unseen.
Is there preferred way to handle this problem?
Version:
SDL2-2.0.9
I just upgraded from 3.1.17 to 4.1.1 and I'm finding a problem with my shopping lists.
When I get to /customer/shoppinglist/5064 I see this:
Looking at my log files from production I see:
[2020-06-23 17:42:56] request.CRITICAL: Uncaught PHP Exception Symfony\Component\ErrorHandler\Error\UndefinedMethodError: "Attempted to call an undefined method named "getDigitalAsset" of class "Proxies\__CG__\Oro\Bundle\AttachmentBundle\Entity\File"." at /usr/share/nginx/html/oroapp/vendor/oro/platform/src/Oro/Bundle/DigitalAssetBundle/Provider/FileTitleProvider.php line 47 {"exception":"[object] (Symfony\\Component\\Debug\\Exception\\FatalThrowableError(code: 0): Attempted to call an undefined method named \"getDigitalAsset\" of class \"Proxies\\__CG__\\Oro\\Bundle\\AttachmentBundle\\Entity\\File\". at /usr/share/nginx/html/oroapp/vendor/oro/platform/src/Oro/Bundle/DigitalAssetBundle/Provider/FileTitleProvider.php:47)"} []
I went to look at the code and I see that in fact there is no method getDigitalAsset in oro/platform/src/Oro/Bundle/DigitalAssetBundle/Provider/FileTitleProvider.php, nor in the proxy... how can this be?
I checked this on my VM (where the problem is not happening) and I see that there's this definition in the proxy class:
/**
* {#inheritDoc}
*/
public function getDigitalAsset()
{
$this->__initializer__ && $this->__initializer__->__invoke($this, 'getDigitalAsset', []);
return parent::getDigitalAsset();
}
But again, I don't see a method called getDigitalAsset in the parent class.
I had some issues when doing the upgrade (I realized my nodejs wasn't upgraded as I thought it was), could that have anything to do with the issue?
Thanks
Edit:
I went through my platform upgrade again and found that there were some problems that prevented it from finishing completely.
This is what I found:
> loading Oro\Bundle\CMSBundle\Migrations\Data\ORM\LoadImageSlider
In LoadImageSlider.php line 117:
Attempted to call an undefined method named "setMainImage" of class "Oro\Bundle\CMSBundle\Entity\ImageSlide".
I commented out the loop inside the load method and re-run the upgrade. Then I got:
> loading Oro\Bundle\CMSBundle\Migrations\Data\ORM\LoadImageSlider
In QueryException.php line 65:
[Semantical Error] line 0, col 117 near 'digitalAsset': Error: Class Oro\Bundle\AttachmentBundle\Entity\File has no association named digitalAsset
In QueryException.php line 43:
SELECT file, digitalAsset, sourceFile FROM Oro\Bundle\AttachmentBundle\Entity\File file INNER JOIN file.digitalAsset digitalAsset INNER JOIN digitalAsset.sourceFile sourceFile WHERE file.parentEntityClass = :parentEntityClass
AND file.parentEntityId = :parentEntityId AND file.parentEntityFieldName =
:parentEntityFieldName
Finally I was able to complete the upgrade by commenting out the whole body of the load method
I had some issues when doing the upgrade (I realized my nodejs wasn't upgraded as I thought it was), could that have anything to do with the issue?
It looks like you have multiple versions of nodejs installed. To make an application use the right one, you can provide the absolute path to the executable with the AssetBundle configuration, like:
# config/config.yml
oro_asset:
nodejs_path: /usr/local/node
npm_path: /usr/local/npm
Call me stubborn, but they can get my /: and :\ out of my cold, dead fingers. I can't wait for scala 2.14 when they are supposed to go away so that I can implement my own and get rid of the deprecation warning completely, but is there anything I can do in the meantime - in scalac, sbt or at least IntelliJ to filter out those warnings? I am an absolute noob with regard to sbt, but it seems like something that should be very easily accomplished.
Scala 2.13.2 has just been released a few days ago, which includes a new -Wconf flag for configurable warnings. See https://github.com/scala/scala/pull/8373
Configure compiler warnings.
Syntax: -Wconf:<filters>:<action>,<filters>:<action>,...
multiple <filters> are combined with &, i.e., <filter>&...&<filter>
Note: Run with `-Wconf:any:warning-verbose` to print warnings with their category, site,
and (for deprecations) origin and since-version.
<filter>
- Any message: any
- Message categories: cat=deprecation, cat=lint, cat=lint-infer-any
The full list of warning categories is shown at the end of this help text.
- Message content: msg=regex
The regex need only match some part of the message, not all of it.
- Site where the warning is triggered: site=my\.package\..*
The regex must match the full name (`package.Class.method`) of the warning position.
- Source file name: src=src_managed/.*
If `-rootdir` is specified, the regex must match the canonical path relative to the
root directory. Otherwise, the regex must match the canonical path relative to any
path segment (`b/.*Test.scala` matches `/a/b/XTest.scala` but not `/ab/Test.scala`).
Use unix-style paths, separated by `/`.
- Origin of deprecation: origin=external\.package\..*
The regex must match the full name (`package.Class.method`) of the deprecated entity.
- Since of deprecation: since<1.24
Valid operators: <, =, >, valid versions: N, N.M, N.M.P. Compares against the first
version of the form N, N.M or N.M.P found in the `since` parameter of the deprecation,
for example `1.2.3` in `#deprecated("", "some lib 1.2.3-foo")`.
<action>
- error / e
- warning / w
- warning-summary / ws (summary with the number of warnings, like for deprecations)
- warning-verbose / wv (show warning category and site)
- info / i (infos are not counted as warnings and don't affect `-Werror`)
- info-summary / is
- info-verbose / iv
- silent / s
The default configuration is:
-Wconf:cat=deprecation:ws,cat=feature:ws,cat=optimizer:ws
User-defined configurations are added to the left. The leftmost rule matching
a warning message defines the action.
Examples:
- change every warning into an error: -Wconf:any:error
- silence certain deprecations: -Wconf:origin=some\.lib\..*&since>2.2:s
Full list of message categories:
- deprecation
- feature, feature-dynamics, feature-existentials, feature-higher-kinds, feature-implicit-conversions, feature-macros, feature-postfix-ops, feature-reflective-calls
- java-source
- lint, lint-adapted-args, lint-byname-implicit, lint-constant, lint-delayedinit-select, lint-deprecation, lint-doc-detached, lint-eta-sam, lint-eta-zero, lint-implicit-not-found, lint-inaccessible, lint-infer-any, lint-missing-interpolator, lint-nonlocal-return, lint-nullary-override, lint-nullary-unit, lint-option-implicit, lint-package-object-classes, lint-poly-implicit-overload, lint-private-shadow, lint-recurse-with-default, lint-serial, lint-stars-align, lint-type-parameter-shadow, lint-unit-specialization
- optimizer
- other, other-debug, other-match-analysis, other-migration, other-pure-statement, other-shadowing
- scaladoc
- unchecked
- unused, unused-imports, unused-locals, unused-nowarn, unused-params, unused-pat-vars, unused-privates
- w-flag, w-flag-dead-code, w-flag-extra-implicit, w-flag-numeric-widen, w-flag-self-implicit, w-flag-value-discard
To suppress warnings locally, use the `scala.annotation.nowarn` annotation.
Note: on the command-line you might need to quote configurations containing `*` or `&`
to prevent the shell from expanding patterns.
For anyone else still stuck with an earlier Scala version, there is the silencer scalac plugin: https://github.com/ghik/silencer
So I'm adding an exception to an existing project but have run into an issue. I have the following compiler flags:
OC_COMPFLAGS = -c $(OC_DEBUG_COMPFLAGS) **-q64** -qcpluscmt -qinitauto=00 $(OC_OPT_COMPFLAGS) -D_RWCONFIG_8d -DXML_LIBRARY **-qlanglvl=ansifor:newexcp** -qlonglong -qfuncsect -bnoquite -bloadmap -qnamemangling=v8
The newexcp flag works perfectly except when we add in the -q64 flag - at which point it stops working. Does anyone have an idea why?
This might be applicable - from http://www-01.ibm.com/support/docview.wss?uid=swg1IY20996:
"The user can get new to throw exceptions by adding the following call to their program:
__set_new_throws_exception(true);