The Pharo dev image ships, by default, with a browser that doesn't seem to have any refactoring abilities. What's the most convenient way to transform a fresh Pharo image into something more useful?
You either download the Pharo Developer Image from the download section on the Pharo Website (it contains a selection of developer tools including the refactoring engine) or you use the following script in a Pharo Core Image:
"Refactoring"
Gofer new
squeaksource: 'rb';
package: 'AST-Core';
package: 'Refactoring-Core';
package: 'Refactoring-Spelling';
load.
"OmniBrowser"
Gofer new
renggli: 'omnibrowser';
package: 'OmniBrowser';
package: 'OB-Standard';
package: 'OB-Morphic';
package: 'OB-Shout';
package: 'OB-Refactory';
package: 'OB-Regex';
package: 'OB-SUnitIntegration';
load.
"Tools"
Gofer new
renggli: 'unsorted';
package: 'Shout';
package: 'RoelTyper';
package: 'ECompletion';
package: 'ECompletionOmniBrowser';
load.
"Select Tools"
SystemBrowser default: (Smalltalk at: #OBSystemBrowserAdaptor).
Can you tell me exactly which Pharo image did you download ? because refactoring tools, and several other developer tools are shipped by default in the Pharo images.
Check the following link: http://gforge.inria.fr/frs/download.php/26681/Pharo-1.0-10515-rc3dev10.03.1.zip
that I got from http://www.pharo-project.org/pharo-download
Thanks
Related
It appears the current versions of google-cloud-logging and google-cloud-storage are incompatible. How on earth does Google think it's okay to have a "platform" where you can't use the latest versions of things together?
If my requirements.txt has:
google-cloud-storage
google-cloud-logging
I get:
WARNING: Found incompatible dependencies: "google-cloud-datastore 1.15.5 has requirement protobuf<4.0.0dev, but you have protobuf 4.21.7
If I try to work around that by adding:
protobuf==3.20.1
Then I get:
WARNING: Found incompatible dependencies: "google-cloud-logging 3.2.5 has requirement protobuf!=3.20.0,!=3.20.1,!=4.21.1,!=4.21.2,!=4.21.3,!=4.21.4,!=4.21.5,<5.0.0dev,>=3.19.5, but you have protobuf 3.20.1.\ngoogle-cloud-appengine-logging 1.1.6 has requirement protobuf!=3.20.0,!=3.20.1,!=4.21.0,!=4.21.1,!=4.21.2,!=4.21.3,!=4.21.4,!=4.21.5,<5.0.0dev,>=3.19.5, but you have protobuf 3.20.1.\ngoogle-api-core 2.10.2 has requirement protobuf!=3.20.0,!=3.20.1,!=4.21.0,!=4.21.1,!=4.21.2,!=4.21.3,!=4.21.4,!=4.21.5,<5.0.0dev,>=3.19.5, but you have protobuf 3.20.1.
Does anyone here know an incantation that actually allows google-cloud-storage and google-cloud-logging to be used at the same time?
Also, if anyone from the GAE team is reading this, will you please get your act together on this, and make the "latest" versions of your SDKs work together? This protobuf issue has been around for a really long time.
Because you are integrating Cloud Datastore, which has a dependency requirement that the protobuf package version be lower than 4.0 use:
protobuf<4
One of my deployment pipelines on Azure DevOps fails when executing the build module images action of Azure IoT Edge task. I am trying to deploy a custom module developed using the Azure IoT SDK for C# (.NET 6).
Error message:
##[error]/usr/lib/python3/dist-packages/requests/__init__.py:89: RequestsDependencyWarning: urllib3 (1.26.12) or chardet (3.0.4) doesn't match a supported version!
I tried to include this solution as CmdLine task before the build task. It worked a few runs and then failed again.
The pipeline already had a "Temporary fix" installing iotedgedev separately as a workaround for this bug
The deployment logs don't tell much about where to focus. I wonder what could be the cause of this issue? and if there is a quick fix or something to avoid while developing the application (i.e. warning messages while building or something like that)
I've had the same problem. After checking previous success Pipelines it seems that then new iotedgedev version 3.3.5 has a problem in DevOps Build Task (I haven't investigate more)
To fix that, at least temporally, I have added a Command Line Script before Build Modules Images Task that installs version 3.3.4.
pip install -U iotedgedev==3.3.4
It has worked for me, but as I said is a temporally patch.
As this appears to happen again and again and again and again (in different flavours), I felt it made sense to explain why this happens. It's right there in the error message actually, in my case:
.local/lib/python3.11/site-packages/requests/__init__.py:102:
RequestsDependencyWarning: urllib3 (1.26.9) or
chardet (5.1.0)/charset_normalizer (2.0.12) doesn't match a supported version!
So, apparently the requests package needs its dependencies at a certain version level to work correctly. But pip doesn't show which versions:
$ pip show requests | grep Requires
Requires: certifi, charset-normalizer, idna, urllib3
Let's look at init.py then, this is where the error occured:
if chardet_version:
major, minor, patch = chardet_version.split(".")[:3]
major, minor, patch = int(major), int(minor), int(patch)
# chardet_version >= 3.0.2, < 5.0.0
assert (3, 0, 2) <= (major, minor, patch) < (5, 0, 0)
....and on it goes, and we can now fiddle around with the expected version strings until the warning goes away or update the requests package to a version that accepts its required packages at the correct versions.
TL;DR: One has to upgrade or downgrade the affected packages (request or its dependencies) to get it right, or fiddle around with requests/__init__.py until the warning goes away :-)
Short answer -> force pyOpenSSL to version 22.0.0
(Edited 09.01.20223)
pip install -U iotedgedev pyOpenSSL==22.0.0 urllib3 requests
The cause seems to be a reported bug related to a dependency issue connected to a new pyOpenSSL release: github.com/Azure/iotedgedev/issues/589
pyOpenSSL>=20.0.1 on iotedgedev requirements resolves pyOpenSSL-22.1.0 creating some conflict with urlib or chardet
In this case, a temporary fix needed a "quick" temporary fix :D
Source maps for other JS bundles are generated correctly, but vendor.HASH.js.map looks like this:
{"version":3,"mappings":"","names":[],"sources":[],"sourcesContent":[],"sourceRoot":"webpack:///","file":"vendor.HASH.js"}
There are not special errors during the build (except a few optimization bailouts due to CommonJS modules and some things about going over budgets).
What am I missing here?
Running on:
Angular CLI: 13.0.4
Node: 12.22.3
Package Manager: npm 6.14.13
OS: darwin x64
Dependencies are a mix of up-to-date libraries and some old packages, but most are updated to last year, as was available.
Config is pretty standard - but code migrated all over from Angular 6, in a series of upgrades over the years.
[I can provide outputs and more config, if needed - but SO formatter complains it makes the question "mostly code"...]
Orchard 1.8. While I can package the default theme successfully (TheThemeMachine) Using the command line instructions from here E.g
orchard> package create TheThemeMachine C:\Temp
packaging my own themes I get the following error
"Cannot create a package that has no dependencies nor content."
(the theme indeed has content)
Anybody have the same issue ? Rookie error I'm guessing..But help much appreciated as error appears undocumented.
This error happens when you have set wrong version for the module/theme. For NuGet it's important to have correct versioning. Make sure you have version in your Theme.txt following formats {x.x}, {x.x.x}, {x.x.x.x} (where x are only digits, each up to 10)
Valid:
1.0
0.0.0.1
01.4423.455.112312
1234567890.1234567890.1234567890.1234567890
Invalid:
1
.1
1.1.1.1.1
1.12345678901
I've seen the following issue mentioned in another thread a few days ago amongst other problems, but the solution for this issue (to me) didn't seem to be addressed.
I recently ran a test on my Ruby 1.9.2-p290 environment and was presented with the following error when I ran a test script:
You are using an old or stdlib version of json gem
Please upgrade to the recent version by adding this to your Gemfile:
gem 'json', '~> 1.7.7'
This issue continued when I created a completely fresh Ruby 1.9.3-p392 environment, running on Windows XP (don't ask). What confuses me is that even when I have json 1.7.7 or 1.8.0 installed (gem list is pasted below), I still get this message when I run my test. It's not really affecting my test results, but the warning is just rather annoying to see each time.
Which Gemfile do I need to add this version into, and where would it be located?
gem list:
bigdecimal (1.1.0)
childprocess (0.3.9)
commonwatir (4.0.0)
ffi (1.8.1 x86-mingw32)
io-console (0.4.2, 0.3)
json (1.8.0, 1.7.7, 1.5.5)
mini_portile (0.5.0)
minitest (5.0.0, 2.5.1)
multi_json (1.7.3)
rake (10.1.0.beta.3, 10.0.4, 0.9.2.2)
rdoc (4.0.1, 3.9.5)
rubygems-update (2.0.3)
rubyzip (0.9.9)
selenium-webdriver (2.32.1)
watir-webdriver (0.6.4)
websocket (1.0.7)
win32-api (1.4.8 x86-mingw32)
win32-process (0.7.2)
windows-api (0.4.2)
windows-pr (1.2.2)
The message is coming from the multi_json gem, and it seems like it could be a bug. I suggest keeping an eye on this GitHub ticket.
If the message is too distressing, you can downgrade multi_json to version 1.6.1 to get rid of it. (At least this works for me.)
UPDATE:
It looks to me like the root of the problem is that while multi_json wants to limit its use of the json and json_pure gems to specific versions, the author of multi_json isn't using the gem method in his code to activate these versions. (It sounds like he thinks Bundler is the only way to specify versions of gems; it isn't.)
Since multi_json will try the oj and yajl-ruby gems before it tries json, using one of those may be the best workaround of all. So you can just install the latest multi_json and then install either oj or yajl-ruby along with it.
Try this:
gem update --system
gem update
Go to your Ruby installation path, for example,
C:\Ruby192\lib\ruby\1.9.1\json
Open version.rb file and update the version detail as shown bellow:
VERSION = '1.7.7'
Try running your tests with the bundle exec command. This will force your environment to use the gems in Gemfile.lock.