I'm using the Headless Chrome Webdriver, and finding my builds suddenly breaking on the build service I'm using. It's happened before, but I think it was fixed by upgrading selenium-devtools.
It seems to me that this is caused by the build server now having Chrome 110 installed, but the current version of the selenium-devtools gem is at 0.109, and yields the following error:
LoadError:
cannot load such file -- selenium/devtools/v110
Did you mean? selenium/devtools/v109
# /home/rof/cache/bundler/ruby/3.1.0/gems/zeitwerk-2.6.6/lib/zeitwerk/kernel.rb:38:in `require'
# /home/rof/cache/bundler/ruby/3.1.0/gems/selenium-devtools-0.109.0/lib/selenium/devtools.rb:26:in `load_version'
# /home/rof/cache/bundler/ruby/3.1.0/gems/selenium-webdriver-4.8.0/lib/selenium/webdriver/common/driver_extensions/has_devtools.rb:34:in `devtools'
# /home/rof/cache/bundler/ruby/3.1.0/gems/selenium-webdriver-4.8.0/lib/selenium/webdriver/common/driver_extensions/has_network_interception.rb:63:in `intercept'
# ./spec/support/interceptor.rb:80:in `start_intercepting'
...
Anyone know a way of getting around it, given that there's no updated selenium-devtools yet?
If my understanding is correct, then there seems to be two ways of fixing this, without completely disabling my feature specs:
Use an older version of Chrome. Not possible on my current build server, I think.
Wait for selenium-devtools v0.110 to be released.
.. neither of which is optimal.
Related
I'm trying to deploy my application on Gigalixir, following the getting started with an existing app.
I have added [{:distillery, "~> 2.1"}] to my mix.deps
building the release for production
SECRET_KEY_BASE="$(mix phx.gen.secret)"
DATABASE_URL="postgresql://postgres:postgres#localhost:5432/rumbl_dev"
MIX_ENV=prod
mix distillery.release --env=prod
But then I run _build/prod/rel/rumbl/bin/rumbl start, and that fails with
Could not locate code path for m{elixir-1.7.2","./lib/elixir-1.7.2!
Any ideas what could be going on?
You should compare elixir version in your mix file and version installed at the server.
On MacOS, the command "unset GREP_OPTIONS" solved this issue for me. I found this issue is relevant to the wrong return value of function __rel_apps() in phoenix/{your-app}/_build/prod/rel/{your-app}/releases/{your-version}/libexec/erts.sh. Then, the solution is referenced from underlying link.
https://github.com/bitwalker/distillery/issues/592
I am trying to run a .tcl file originally configured for 2014.4 on 2016.4 version of Vivado. However I am getting the following error:
while executing
"create_bd_cell -type ip -vlnv xilinx.com:ip:mig mig_0 "
(procedure "create_root_design" line 111)
invoked from within
"create_root_design """
(file "all.tcl" line 405)
The tcl file uses the part 'xcku040-ffva1156-2' and tries to access the IP 'mig' which I believe is renamed/changed on later versions. Is there any workaround for this?
Steps I have done till now:
Changed the version number to 2016.4
tried replacing target boards.
tried on the same board with an alternate IP for mig.
tried on both 2016.4 and 2015.4 versions
None of these have worked so far
Attaching the '.tcl' file for reference : all.tcl
Since with every version upgrade of the Vivado Design Suite, parts are renamed or removed, it is not possible to run a .tcl file meant for an earlier version in newer releases. So I ran the above query on Xilinx Community Forums and found a workaround:
Run this script on the previous version(2014 in this case), generate the design and then open the same design using the next major release(2015 version). The 2015 version will automatically suggest upgrades to the discontinued/renamed IPs. Repeat the same to get to 2016 version. That's the only way to get this done. Also have to keep checking if the core functionality of the IP is the same after automated upgrades by Vivado Design Suite.
I am using Grails 2.4.0.RC1 (and JDK 1.7.0_55) and whenever I browse to any app view that makes use of javascript files from the web-app folder, the java process seems to lock those files.
So I cannot work on any of those javascript files any more since when I try to save changes Windows 7 will not let me do it.
I used Process Explorer to check which process is locking the files and it's the java process running the grails app indeed.
At first I thought that this problem could be related to the new asset-pipeline:1.8.7 plugin which I am using. So I uninstalled it to check if the problem was still there... and it was.
The same app was running on Grails 2.3.5 just fine (although we were using an older JDK too... I must check with JDK 1.7.0_55).
By the way, something similar happened with a much older version of Grails: https://jira.grails.org/browse/GRAILS-3585
Is Anyone experiencing the same problem?
UPDATE 1:
I have tested this problem running the app on different versions of java and these are my results:
Win7-64bits, grails2.4.0.RC1, jdk1.7.0_55 -> PROBLEM OCCURS
Win7-64bits, grails2.4.0.RC1, jdk1.7.0_25 -> PROBLEM OCCURS
Win7-64bits, grails2.4.0.RC1, jdk1.6.0_18 -> OK
UPDATE 2:
I created a blank app (which uses Tomcat by default) and everything works fine.
The same blank app using jetty-plugin (with Jetty8) DOES present the problem.
I am further investigating this now.
I found the problem.
It had to do with the jetty-plugin indeed.
On the official version of the plugin 2.0.3 which uses Jetty7, the locking problem is NOT present. But this plugin uses a very old version of Jetty, so it's no use.
On the branch of the plugin created to run Jetty8:
https://github.com/grails-plugins/grails-jetty/tree/2.0.x
... the problem is there.
Also, on the new grails jetty plugin version 3.0.x (which uses Jetty 9.0.x), the problem is there too!
UPDATE 1:
Have a look at:
Jetty locking static files in Windows
Apparently the "useFileMappedBuffer" init-param of Jetty has to be set to false to prevent file locking.
You can use a local version of the jetty plugin and modify the above-mentioned property on [jetty-plugin]/grails-app/conf/webdefault.xml
Im using bower as part of the yeoman 1.0 beta 4 install. All looks well however when I run bower install I get the expected output yet no files are copied to app/components as advertised.
I am running on windows which I understand is not officially supported yet. Has any one managed to get this up and running with some success? I have followed some tutorials on line relating to the subject however I think they are out dated. I managed to install yeoman without any additional steps and no errors as far as I can tell.
Grunt File being Used
Oh no... Git was not on the system path. Adding it caused me to run into another small error with a solution found here http://wingkaiwan.com/2012/11/25/bower-errors-on-windows/
Thank you Mr Ricky Wan
I keep getting the same type of error messages and I have really done all I can to get rid of them. The message is as follows, only the module can vary at times:
ruby 5740 child_info_fork::abort: address space needed by 'date_core.so' (0x600000) is already occupied
These messages occur at various times when trying to run Rails, such as “rails console”.
I am running the following environment:
Windows 7 Ultimate 64-bit
Cygwin Net using setup 2.774 (installed from Internet mirrors)
Ruby 1.9.3p392
Rails 3.2.11
I have taken the following steps attempting to fix this:
Deleted all BLODA and restarted, including Norton 360 and Malwarebytes. (BLODA is Big List of Dodgy Apps.)
Deleted and reinstalled Cygwin.
Executed “rvm implode” and rebuilt the RVM and Ruby on Rails environment.
Used CMD & ASH to run “peflagsall” & “rebaseall”. Ran “rubyrebase”. Restarted.
Used FIND to build a file of all *.so & *.dll files. Ran “rebase -T”. Restarted. This has also been done using the “-b 0x77000000” switch.
Used same file to create “to_peflags” script issuing peflags against each individual file. Restarted.
All repair attempts have been futile. At times, “rebase -si |grep ‘*’” would be clean. Any attempt to run “rails console” or similar commands results in Address Space Occupied messages. Subsequent “rebase -si” would then again show conflicts.
I have been trying to run “peflags” against the Ruby modules, but I only get “skipped because could not open” error messages there. File permissions and ACL both show correct permissions. The same error occurs whether or not Administrator is used.
This is pretty frustrating. I would like to fix my current environment, but I am considering moving to MSYS or SFU, but I don’t know if either of those are decent options. I am also considering going native UNIX, but I’ll leap off the cliff when I get to it.
For now, does anyone have a fix for this specific error for me? Thanks…
I have used procexp to monitor "rails console" execution. Bash is calling cmd.exe to run the rails.bat file. Cmd.exe runs in ASLR mode. Used Microsoft EMET 3.0 to turn off mandatory ASLR and bottom up ASLR for both bash and cmd. Cmd.exe still runs in ASLR mode. It must be compiled that way.
Updated registry to set HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages to 0, -1 then 1. 0 caused system problems. -1 had no effect. 1, which was supposed to be the default, helped somewhat as long as EMET changes were in place. But, it was unreliable as Address Space Occupied would eventually recur.
Decided to attempt to install a command processor that either didn’t require ASLR or allowed me to disable it using PE flags. I installed TCC/LE and attempted to get Cygwin Bash to use it to process .bat files. I tried using the path variable, the COMSPEC variable and changes to batfile and cmdfile in the registry all to no effect. Cygwin Bash must either have it hard coded or some nonobvious control.
My fix is to replace my environment. I know I will eventually migrate to some Unix, but for now I am converting to MinGW/MSYS and RubyStack. All I want to do is to get a stable RoR (Ruby on Rails) environment running for today. I don’t see that happening using Cygwin with Windows 7 Ultimate. I keep running into too many problems and this one is a very, very tough nut to crack. Thanks…