ubuntu#ip-172-31-32-122:~/src/tensorflow$ bazel-bin/tensorflow/examples/image_retraining/retrain --help
usage: retrain.py [-h] [--image_dir IMAGE_DIR] [--output_graph OUTPUT_GRAPH]
[--output_labels OUTPUT_LABELS]
[--summaries_dir SUMMARIES_DIR]
[--how_many_training_steps HOW_MANY_TRAINING_STEPS]
[--learning_rate LEARNING_RATE]
[--testing_percentage TESTING_PERCENTAGE]
[--validation_percentage VALIDATION_PERCENTAGE]
[--eval_step_interval EVAL_STEP_INTERVAL]
[--train_batch_size TRAIN_BATCH_SIZE]
[--test_batch_size TEST_BATCH_SIZE]
[--validation_batch_size VALIDATION_BATCH_SIZE]
[--print_misclassified_test_images] [--model_dir MODEL_DIR]
[--bottleneck_dir BOTTLENECK_DIR]
[--final_tensor_name FINAL_TENSOR_NAME] [--flip_left_right]
[--random_crop RANDOM_CROP] [--random_scale RANDOM_SCALE]
[--random_brightness RANDOM_BRIGHTNESS]
Looks like there is no --architecture option available. If you pass it, the script will just ignore it without complaining. This means inception is the only option for retraining. Is it intended here?
Here is how I built the script:
/usr/local/bin/bazel build tensorflow/examples/image_retraining:retrain
Bazel version:
ubuntu#ip-172-31-32-122:~/src/tensorflow$ /usr/local/bin/bazel version
............................
Build label: 0.5.2
Build target: bazel-out/local-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Jun 27 13:27:03 2017 (1498570023)
Build timestamp: 1498570023
Build timestamp as int: 1498570023
I am not sure if this doubt still exists, however, if it still does: In the new version of tensorflow (version 1.7.0), the team have introduced "--tfhub_module" as an argument which is now used to control the architecture you want to use for retraining your model. With this argument, many new architectures like NASnet and PNASnet have been introduced. You can find the original code here.
Related
#!/usr/bin/dyalog -script
⍝ /usr/bin/dyalog is a symlink to /opt/mdyalog/18.0/64/unicode/mapl
factors←{⎕ML ⎕IO←1 ⋄ ⍵{ ⍵,(⍺÷×/⍵)~1}∊⍵{(0=(⍵*⍳⌊⍵⍟⍺)|⍺)/⍵}¨⍬{nxt←⊃⍵ ⋄ msk←0≠nxt|⍵ ⋄ ∧/1↓msk:⍺,⍵ ⋄ (⍺,nxt)∇ msk/⍵}⍵{ (0=⍵|⍺)/⍵}2,(1+2×⍳⌊0.5×⍵*÷2),⍵}
factors 20
Copied from https://dfns.dyalog.com/c_factors.htm
It works exactly as the example apart from the fact I am not able to to type it as separate lines and have to resort to ⋄'s
Using the example it instead results in
./.local/src/sandbox/apl/Main.apl
SYNTAX ERROR
factors←{⎕ML ⎕IO←1 ⍝ Prime factors of ⍵.
Another issue is using ] commands like ]display or ]box on
Using them always results in
./.local/src/sandbox/apl/Main.apl
VALUE ERROR: Undefined name: ⎕SE.UCMD
Try* adding setting DYALOG_LINEEDITOR_MODE to 1:
#!/usr/bin/dyalog -script DYALOG_LINEEDITOR_MODE=1
When running in script mode, SALT, and therefore user commands, are not initialised automatically. As per APLcart, you can enable both with:
(⎕NS⍬).(_←enableSALT⊣⎕CY'salt')
However, under program control, you're usually better off using proper functions than user commands. You can copy in the display and disp functions (which take an array and produce character matrices equivalent to what you'd see from ]display and ]box on) with:
'display' 'disp'⎕CY'dfns'
* Both -script and DYALOG_LINEEDITOR_MODE are experimental in version 18.0, while 18.2 (scheduled for release in March 2022) has dedicated #! script support.
I am using the following CLI:
M5_PATH=/home/febin/Storage/Gem5/gem5ist/m5/system/ Gem5/gem5/build/X86/gem5.opt --debug-flags=Cache,Exec,DRAM,TLB Gem5/gem5/configs/example/fs.py --kernel x86_64-vmlinux-2.6.22.9 --num-cpus=64 --num-dirs=64 --caches --elastic-trace-en --num-l2caches=16 --ruby --network=garnet2.0 --topology=Mesh_XY --mesh-rows=8 --command-line="paper3/Blackscholes/blackscholes.out 1 paper3/Blackscholes/in_16.txt paper3/Blackscholes/output.txt" >> paper3/Gem5_fs
I am able to see Exec, DRAM and TLB traces; but I cannot see any data from Cache. Same for SE simulations why is this ?
As mentioned by Daniel, you have to use --debug-flags RubyCache for ruby.
The flag is different because Ruby models the caches itself separately from the classic system.
How do I get gvim to recognize sqlcomplete.vim commands?
I'm unable to use the sqlcomplete.vim plugin. When running :version I get the following output:
and scrolling all the way to the bottom here is the rest of the output:
and the env variables:
:echo $VIM
c:\users\me\.babun\cygwin\etc\
:echo $HOME
H:\
Here is the output of :scriptnames:
When running the sqlcomplete.vim command such as :SQLSetType sqlanywhere the output I get is:
How do I get gvim to recognize sqlcomplete.vim commands?
Another piece of helpful information is the output of :echo &rtp :
H:\vimfiles,H:\.vim\bundle\Vundle.vim,H:\.vim\bundle\dbext.vim,H:\.vim\bundle\SQ
LComplete.vim,C:\Users\me\.babun\cygwin\etc\vimfiles,C:\Users\me\.babu
n\cygwin\etc\,C:\Users\me\.babun\cygwin\etc\vimfiles/after,H:\vimfiles/afte
r,H:\.vim/bundle/Vundle.vim,H:\.vim\bundle\Vundle.vim/after,H:\.vim\bundle\dbext
.vim/after,H:\.vim\bundle\SQLComplete.vim/after
Some points you could check:
:scriptnames shows plugin\sqlcomplete.vim
But the link you provided points to .../vim/runtime/autoload/sqlcomplete.vim, there is no .../vim/runtime/plugin/sqlcomplete.vim, and the version at vim.org also doesn't contains a /plugin file:
install details
Copy sqlcomplete.vim to:
.vim/autoload/sqlcomplete.vim (Unix)
vimfiles\autoload\sqlcomplete.vim (Windows)
For documentation:
:h sql.txt
Maybe you have installed it incorrectly.
The file on your link has version 12 at its header, while the latest version is 15. Try updating to the latest version
Note that this plugin does not define the SQLSetType command.
You could check that by simple searching the file the on link. And on its header:
" Vim OMNI completion script for SQL
" Language: SQL
" Maintainer: David Fishburn <dfishburn dot vim at gmail dot com>
" Version: 15.0
" Last Change: 2013 May 13
" Homepage: http://www.vim.org/scripts/script.php?script_id=1572
" Usage: For detailed help
" ":help sql.txt"
" or ":help ft-sql-omni"
" or read $VIMRUNTIME/doc/sql.txt
Following :help sql.txt:
2.1 SQLSetType *sqlsettype* *SQLSetType*
--------------
For the people that work with many different databases, it is nice to be
able to flip between the various vendors rules (indent, syntax) on a per
buffer basis, at any time. The ftplugin/sql.vim file defines this function: >
SQLSetType
And scriptnames is not listing ftplugin/sql.vim
I'm trying to test the continuation facility in Pharo, with this code(in the playground):
| cont f |
f:=[
|i|
i:=0.
Continuation currentDo: [ :cc | cont:=cc ].
i:=i+1.
].
f value. "1"
cont. "a Continuation"
However, as soon as I call the continuation saved in cont(replacing cont. by cont value.), the image freezes immediately, and I have to press atl+. to gain back control.
VM version: VM: NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm#gmail.com> Jenkins build #14826
Pharo version: [version] 4.0 #40614
Thanks.
Edit: I was stupid, didn't think this through...
You've effectively created an infinite loop by reevaluating the same code again and again. You can see that if you debug the code and step through it. The original context will always be restored and then evaluated starting with the first expression following the #currentDo: send. This is exactly what the continuation is supposed to do: save the current position in the execution and restart there later on.
I do not have a Fedora to test, however I tried your code in Ubuntu, using this version of Pharo:
wget -O- get.pharo.org/40+vm | bash
./pharo-ui Pharo.image
and your code seems to work properly :(
In case this error persists, could you be more specific about the version of the vm you are using?:
./pharo Pharo.image --version
And the version of Pharo you are using?:
./pharo Pharo.image printVersion
Also, send us the crash.dmp file would help a lot.
We are trying to test the co-simulation options of Dymola and created a fmu-file. We installed/built the FMILibrary-2.0b2 and FMUChecker-2.0b1 from www.fmi-standard.org.
I encountered an issue while trying to run the FMUChecker (fmuCheck.linux32) of a fmu-file my colleague created with Dymola. Wenn i create with my Dymola-license an fmu-file from the same Dymola model this issue is not reproducible. Because fmuCheck.linux32 runs fine without any error messages.
My colleague can run both files without problems!
As it is our goal to use this option for co-simulation i tried to run the fmu file on a pc without Dymola and again i got the same error with both my fmu-copy and the one my colleague created.
Here's the Error Message
fmuCheck.linux32 PemFcSysLib_Projects_Modl_SimCoolCirc.fmu
[INFO][FMUCHK] Will process FMU PemFcSysLib_Projects_Modl_SimCoolCirc.fmu
[INFO][FMILIB] XML specifies FMI standard version 1.0
[INFO][FMI1XML] Processing implementation element (co-simulation FMU detected)
[INFO][FMUCHK] Model name: PemFcSysLib.Projects.Modl.SimCoolCirc
[INFO][FMUCHK] Model identifier: PemFcSysLib_Projects_Modl_SimCoolCirc
[INFO][FMUCHK] Model GUID: {6eba096a-a778-4cf1-a7c2-3bd6121a1a52}
[INFO][FMUCHK] Model version:
[INFO][FMUCHK] FMU kind: CoSimulation_StandAlone
[INFO][FMUCHK] The FMU contains:
18 constants
1762 parameters
26 discrete variables
281 continuous variables
0 inputs
0 outputs
2087 internal variables
0 variables with causality 'none'
2053 real variables
0 integer variables
0 enumeration variables
34 boolean variables
0 string variables
[INFO][FMUCHK] Printing output file header
time
[INFO][FMILIB] Loading 'linux32' binary with 'standard32' platform types
[INFO][FMUCHK] Version returned from FMU: 1.0
[FMU][FMU status:OK]
...
[FMU][FMU status:OK]
[FMU][FMU status:Error] fmiInitialize: dsblock_ failed, QiErr = 1
[FMU][FMU status:Error] Unless otherwise indicated by error messages, possible errors are (non-exhaustive):
1. The license file was not found. Use the environment variable "DYMOLA_RUNTIME_LICENSE" t
[FATAL][FMUCHK] Failed to initialize FMU for simulation (FMU status: Error)
[FATAL][FMUCHK] Simulation loop terminated at time 0 since FMU returned status: Error
FMU check summary:
FMU reported:
2 warning(s) and error(s)
Checker reported:
0 Warning(s)
0 Error(s)
Fatal error occured during processing
I think a fmu-file shouldn't need a Dymola license to be simulated, therefore i can't see the reason this simulation failed.
What could be the reason for this strange behaviour?
Partially this is the same Error Message of this Issue
Initialization of a Dymola FMU in Simulink
Any suggestions are much appreciated. Thank you.
It seems that dymola has not set the path variable to the license-file in ubuntu. We have done this manually by adding the following lines to .bashrc
# Dymola runtime license, path
DYMOLA_RUNTIME_LICENSE=$HOME/.dynasim/dymola.lic
export DYMOLA_RUNTIME_LICENSE
now we can simulate each others fmu-files!
Whether an exported FMU requires a license depends on whether the copy of Dymola that exported the FMU had the "Binary Export" feature. The bottom line is that if you want unencumbered FMUs from Dymola, you have to pay for an extra licensed feature.